Normalisation and W3C with particular reference to CSS -- 17 Jun 2011

<scribe> scribenick: ChrisL

plh: Primary goal is to move css selwsctors forward

http://www.w3.org/wiki/I18N/CanonicalNormalization

http://lists.w3.org/Archives/Public/www-style/2009Feb/0231.html

http://www.w3.org/International/docs/charmod-norm/

peter, is dbaron's preserence for normalise-at-parse expressed somewhere other than his 2009 summary linked above?

http://lists.w3.org/Archives/Public/www-style/2009Feb/0231.html was wikified (link above)

http://www.w3.org/wiki/I18N/CanonicalNormalization

<plh> http://test.csswg.org/harness/results/CSS21_DEV/

<plh> http://test.csswg.org/harness/results/CSS21_RC6/

<plh> http://www.w3.org/Style/CSS/Test/

plh: css ns blocked on normalisation issue, which also blocks css selectors

<plh> http://www.w3.org/TR/2008/CR-css3-namespace-20080523/

http://dev.w3.org/CSS/css3-namespace-test-suite/

plh: norm is not done on the identifier. implementors not willing to do so

plinss: yes

aphillipisson: we dont require full normalisation of docs or stylesheets but we want normalised compare especially for identifiers and namespaces
... same ns or not should nor depend on source encoding or order of combining marks

plinss: so you said you dont want to normalise selectors?

aphillip: not require stylesheets to be in a particular form
... comparisons should be normalised
... but not random text selection

ChrisL: 'early' norm can men by content autors or at parse time; which do you mean

aphillip: content is not normalised all the time. so user agents are responsible.
... should they normalise at parse or compare

r12a: may be a reason to have denormalised text in content. but different for class selectors, id s etc which are compared
... may make sense to normalise just those

aphillip: interactions with dom and exmascript
... wg position is to focus on comparison being normalised. dont care how its done. normalising identifiers at parse time is one way

plinss: so you see that as just an implementation detail?

aphillip: there can be side effects from that choice
... harder to normalise individual tokens, but possible. then question is which tokens

plinss: and what does the dom see and what does script assume

aphillip: so yu can't make certain queries anymore

plinss: not sure how this is particular to nnamespaces

aphillip: ns is a token plus an IRI. want them to compare in a normlised fashion
... so can tell what ns is in use regardless of document encoding

r12a: mac vs pc normalisation ...

aphillip: mainly filenames there
... also vietnamese keyboard different on mac and pc wrt normalisation so you get two different strings that look the same

plinss: no namespaces in css are like xml - you take a uri and give it a prefix to use. you want to notmalise the prefix or the uri?

aphillip: uri has no non-ascii. iri has the rues in it (or will have) for how that works. so main concern is the prefix that has to be unique

plinss: prefix in css is an ident. so we would have to normalise all idents. but we have author deined idents - why pick on ns in particular

aphillip: coparisons should be normalising for identifiers

plh: so we just published css as a rec, and it defines an ident. so why does this apply to css ns and not css 2.1

aphillip: it does apply to css 2.1
... the horse has escaped. so i18n wg is in catch up. not been succesful so far.
... last vestige of attempt to normalise is to getidentifiers normalised. if we cant do that then we are done
... valid for us t question whether we are doing the right thing to put the onus on content authors to sort it out

plh; for styling, if the class or id does not match you will see right away

aphillip: stylesheet may be dynamically generated and separae from the doc. author can't see why it doesnt work

plinss: yes, but that does not apply here as ns prefixes are local to the scope of a single stylesheet. only the uri is matched internallt
... so there is a consistent normalisation. unrelated to any prefixes used in the document
... any unicode in an author defined ident is in the one document

aphillip: or if you use escapes

plinss: esapes should not be normalised anyway

aphillip: ok, thats not so ....

plinss: css ident is asci wit unicode escapes, we dont apllow random unicode in there

aphillip: think you allow a reasonable range

plinss: a small range
... i see classes as an issue certainly, but also attribute selectors. but none of that applies to namedspaces

<plh> ident [-]?{nmstart}{nmchar}*

<plh> name {nmchar}+

<plh> nmstart [_a-z]|{nonascii}|{escape}

<plh> nonascii [^\0-\237]

plinss: and frankly that applies right back to css1
... if we want norm we should require it all the places tat it matters. every place the author can type an ident. or nothing
... happy to support that but this is ot the place to make the stand

aphillip: our comments actually went to selectors first. its kind of a test case as someone has to do something to decisde which directionw e go
... are we going to normalise some important thins or not. if not then the guidelines need to be changed so people know what to avoid
... didnt go to ns til the end. started with selectors
... this is a relaxation f out position 5 yerars ago which was noralise everything
... realise this is problematic

r12a: and we need to get html to norm at the same time

plinss: lots of things do selection

aphillip: out position is that we recomend css wg , and we wont object to publishing css ns without it

r12a: yes
... but wanted to be sure we asked the question

aphillip: concerned about selectos. concern is we have a web tha is not normalised and not normalising

plh: bring it to the tag?

aphillip: yes (again)
... dont want to make recommendatins that are destructive and pointless
... started work towards fixing charmod to say the right thing
... only question mark is whether comparisons are normalised

plinss: csswg see this way outside scope of css
... normalising idents needs to have a norm story for comparing outside the stylesheet, so affects html

aphillip: and you shouldnt assume the docs are normalised

plinss: has implications on html
... if css normalises a class name but javascript doesnt then there is an issue
... needs to go tot tag and be consisten on all specs
... tag finding would be very useful. dont want to see a mismatch on identifier handling

plh: also orm on fragment identifiers

aphillip: potentially
... iri may require that but not currently
... speaking not as the chair,the horse is out so i suspect we wont do any of this
... too many leaks to fix
... want to avoid inconsistency
... wg thinks we should at least make an effort
... tag finding is best way

plh: css1 css 2.1 - its too late to change tat

cnt change selectors in css2

r12a: can start wt next version

plh: no
... css3 selectors have to be backward comat with css 2.1 as there is no versioning in css

r12a: in practical terms it would be backwards compar as only a handful of people would rely on this

aphillip: this isnt a hugely breaking change its a subtle change for almost everyone

plh: makes it even harder to sell

ChrisL: everyone will notice if all comparisons are slower

aphillip: only if its a major slowdown

plinss: this is why implementors prefer nortm at parse time. but that is a sepatrate detail
... main focus is what to do with namespaces
... takin it to tag is the right way to go. needs a champion on the tag
... once we have a stor thatgoes across html and dom and css then we can change thngs

plh: so .... what do we do
... brig it to tag with peter
... and css wg decides then moves to pr with css ns
... these could be done together
... its blocked since 2009 and is not productive

aphillip: formal objection is not productive

plh: want the issue t be looked into if css wg moves forward

aphillip: specially concerned abot nt impacting html5 more than needed

<scribe> ACTION: r12a to bring normalisation of idents to tag [recorded in http://www.w3.org/2011/06/17-cssns-minutes.html#action01]

plh; hw ln for a ransitin rewuest

plin: less than a week

<aphillip> aphillipdison: i18n will not formally object to NS, but we very well could do so for Selectors

plinss: tag currently focussed on microdata vs rdfa. so at least a few weeks

r12a: i18n will require a lot longer than that
... and aftyer a tag ruig would require a lot more time than that
... so is it worth holding up css ns and selectors?

aphillip; if selectors is published without norm then its the end of the road

r12a: we have done ok without it so far. there wil be new versionsin the future

plinss: selectors level 4 is already being worked on

aphillip: more time that passes the harder it is to effect change here
... its selectos, ecmascript, dom etc

plh: this is already implemented in older browsers

plinss: selectos 3 added mainly pseudoclases it does not change the comparisons much

ad: we last published charmod-norm 6 years ago. the we got browbeaten into not requirin early normalisation
... its untenable then and we have worked on it for 1 years. so 16 years on we are no closer to accomplishig it

plinss: because css is modular, norm affect much more than jus selectors
... so we would want a normalisation update to 2.1 that covers all idents

ad: dont want the i18n wg focused on this corner case for all eternity
... not being helpful by hitting norm every couple of years
... we can ask for the tags attention and it may be thre weeks or so before we get even a reply
... will take us that long to get a discussion document

plh: counting on peter to advocate for this being on thw agenda

plinss: happy to do so

plh: ok so for ns, my sentiment is that we are better off letting css ns and selectors progress
... because a lot of chang eis needed and its not limited to just those two
... so css wg shoudlrequest PR on both noting te issue is not closed byut asking to move forward

<scribe> ACTION: plinss request PR transition for css namespaces and css selectors, once tag is alerted [recorded in http://www.w3.org/2011/06/17-cssns-minutes.html#action02]

plh: come back to this in a few weeks with the request i hand

adjourned

- DRAFT -

Normalisation and W3C with particular reference to CSS

17 Jun 2011

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output