Re: [whatwg] [html5] Pre-Last Call Comments
Am Mittwoch, den 03.06.2009, 13:23 +0200 schrieb Kristof Zelechovski: The validator generates an error for the classid attribute (in line with what the specification says, I think). An error, unlike a warning, breaks any complex process that depends on successful validation of the components. Why should you care about validation at all in this case (using proprietary non-standard technology) ? I think the specification text should be rephrased so that the validator can issue a warning instead. For the time being, the only practical workaround for this incompatibility is to use Internet Explorer magic comments. What's wrong with that ? Cheers, -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] [html5] Pre-Last Call Comments
The ActiveX components I use are proprietary non-standard technology. Granted. However, the interface to them, HTML, is standard and non-proprietary. Of course, one can use proprietary extensions like namespaces and data sources as well, and sometimes it is necessary for rendering and data management, but the classid attribute has not been the case until (yesterday). Valid code simply makes a better interface overall, which means validating it makes sense. Using IE magic comments causes the validator to skip not only the parts that have been invalidated, such as the classid attribute, but also the parts that would be valid otherwise. If there is error in there, it will go undetected, which is bad. Chris
Re: [whatwg] [html5] Pre-Last Call Comments
On Sun, 5 Apr 2009, Giovanni Campagna wrote:
A few comments, as requested by Ian Hickson.
- End of 2.2.1, a typo: JavsScript instead of Javascript
Fixed.
- From section 2.4.2 I don't understand if boolean attributes with
invalid values represent true or false. In addition, I don't
understand if an empty value is false (as in XHTML1.0) or true (as in
HTML4, because of the minimized syntax).
From my experience, I expect that the empty string (which is
equivalent to not specify the attribute at all) is false, and any
other value is true.
The spec says The presence of a boolean attribute on an element
represents the true value, and the absence of the attribute represents the
false value; is that not clear?
- In 2.4.3 I don't see the point of all the digression about
contentEditable, since it is noted that it doesn't work like that. I
would leave the note to just Note: The empty string can be one of the
keywords or Note: The empty string can a valid keyword
Done.
- In 2.4.4.3 (and maybe in other places) I would prefer [A|E]BNF
instead of the prose description of a floating point number.
It's not obvious to me that this would be any clearer.
I'm also not sure that the normative algorithm is needed.
You mean for parsing? How else would you know how to parse it? In some of
the cases the algorithms don't accept any errorneous content at all, but
in many cases we have to define how you handle bogus data, and I don't see
how to do that any other way.
I've also searched IEEE, IETF, ECMA, ISO and ANSI for another normative
version of the syntax and processing, but I've found none. If you think
that it is important to have it specified completely, you may submit an
ID, so future technologies won't need to rewrite it again.
I'm not sure to what you refer. I certainly wouldn't want anyone reusing
most of these definitions; many are the result of years of bugs causing
legacy content to depend on weird quirks.
- The second paragraph in 2.4.5.6 is hard to understand because the
verb is at the end. I would rewrite as A week-year with a number *yr*
has 53 weeks if corresponds to a year *yr* in the proleptic Gregorian
calendar that has a Thursday as its first day (January 1st), or if
*yr* where *yr* is a number divisible by 400, or a number divisible by
4 but not by 100. In all other cases it has 52 weeks
Done.
Also, don't rely on styles alone, use different words for identifiers
and prose. This includes also the Note following, where no styles are
applied and it is difficult to understand that year year is not a
typo but rather is the year numbered year.
I made the note use y, but in general I find using anything but year
here gets really ugly.
- Can't be simply referenced CSS3 Color in 2.4.6?
This way, implementors could have body[bgcolor] { background-color:
attr(bgcolor,color,white); } in the default CSS instead of using HTML5
specific rules.
The rules for parsing a legacy color value are very constrained and don't
match CSS, no.
- In 2.4.9 a valid hash reference must be equal to an ID, name is
supported only for backward compatibility.
No, map uses name=.
- Section 2.6 is superfluous: handling of application cache is specified
in the appropriate section, handling of HTTP requests and caches is
defined in RFC2616, handling of cookie is defined in the appropriate RFC
(I don't remember the number), handling of about:blank is in the
proposed about-uri-scheme ID. In addition, serialized queue-based
handling of resources should not be mandated by the HTML5 specification
(can't UAs be multi-threaded?)
Section 2.6 (fetching) is needed to define how the fetching algorithm
(HTTP, etc) fit into the event loop mechanism and the storage mutex.
- Rewriting 2.6.1 without the HTTP word is definitely better. Browsers
are not required to support HTTP, AFAIK. You can write a GET method
(because GET is anyway an English word), a response code (most
protocols have response codes) and metadata (instead of headers, that
SMTP, POP, FTP don't support)
I think that would be far less clear.
- 2.6.2 should be implied by the HTTP-over-TLS RFC
Apparently implying it isn't good enough, given current implementations.
- In section 2.7.1, in sentence Extensions must not be used for
determining resource types for resources fetched over HTTP., do you
mean File extensions, like .txt or .png, or User agent extensions
(additions to the algorithm)?
This is fixed in Adam's draft now.
- Still in section 2.7.1, why the algorithm is a violation of RFC2616?
Because it is case insensitive? Because it allows spaces? Because it
does not imply ISO-8859-1 if no charset is explicit? Because it does not
imply ASCII for text/* mime types?
Because it means not blindly honouring Content-Type.
- Why don't you add ?xml to the sniffing table?
I'll leave this up to Adam.
- In section 2.8, x-x-big5 is not a different encoding than big5,
it
Re: [whatwg] [html5] Pre-Last Call Comments
On Sun, 5 Apr 2009, Kristof Zelechovski wrote: Now that classid is gone, what will be the workaround for ActiveX objects where they are needed? ActiveX controls are a vendor-specific technology, and thus not appropriate for explicit support in HTML5 (just like we dropped applet). The real workaround is use HTML, CSS, JS, DOM, or, if you really need a plugin, use a type that triggers the right plugin. 2. Use a custom DTD with classid for validation? That doesn't make the document valid. 3. Use a custom type application/vnd.acme-fancy-control+oleobject for every control? Yes. Of course, such things are inherently nonportable but they are widely used. It would be nice to have a way to validate them. You can. If you use it the validator will tell you you're doing something non-portable. This is intentional! -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [html5] Pre-Last Call Comments
On Sun, 5 Apr 2009, João Eiras wrote: The spec does not forbid to use non supported attributes and elements. Actually, it does. I've just made the spec even clearer about this, though. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [html5] Pre-Last Call Comments
On Sun, 5 Apr 2009, Christoph Päper wrote: Giovanni Campagna: - The second paragraph in 2.4.5.6 is hard to understand because the verb is at the end. I would rewrite as A week-year with a number *yr* has 53 weeks if corresponds to a year *yr* in the proleptic Gregorian calendar that has a Thursday as its first day (January 1st), or if *yr* where *yr* is a number divisible by 400, or a number divisible by 4 but not by 100. In all other cases it has 52 weeks | A week-year with a number $year that corresponds to a year $year in the | proleptic Gregorian calendar that has a Thursday as its first day | (January 1st), and a week-year $year where $year is a number divisible | by 400, or a number divisible by 4 but not by 100, has 53 weeks. All | other week-years have 52 weeks. The description is wrong anyhow: Not every leap year has 53 weeks! (For instance, 2008 and 2012 have 52 weeks only.) The difference to common years is that leap years with 53 weeks can have Jan01 on either Thu or Wed, because Dec31 then is Fri or Thu respectively. (Compare your 2020 to your 2004 calendar.) Fixed, thanks. Or just reference and rely on ISO 8601. That is what references (especially to standards) are for after all. I would, except that ISO8601 costs 130 CHF and it seems far easier for everyone concerned to just add the paragraph right there instead of deferring to some paragraph elsewhere. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [html5] Pre-Last Call Comments
The validator generates an error for the classid attribute (in line with what the specification says, I think). An error, unlike a warning, breaks any complex process that depends on successful validation of the components. I think the specification text should be rephrased so that the validator can issue a warning instead. For the time being, the only practical workaround for this incompatibility is to use Internet Explorer magic comments. IMHO, Chris
Re: [whatwg] [html5] Pre-Last Call Comments
Regarding http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure. html#weeks: A week begins on Sunday, not on Monday. However, under the present assumption: Better: A week-year has 53 weeks if the first day of the year (January 1st) in the proleptic Gregorian calendar is Thursday or the year is leap and the first day of the year (January 1st) in the proleptic Gregorian calendar is Wednesday. All other week-years have 52 weeks. Better still: A week-year has 53 weeks if February the 28th in the proleptic Gregorian calendar is Saturday or February the 29th in the proleptic Gregorian calendar is Saturday. All other week-years have 52 weeks. Also note, x-x-big5 cannot be registered with IANA because it is already registered for private use. HTH, Chris
Re: [whatwg] [html5] Pre-Last Call Comments
Kristof Zelechovski wrote: Regarding http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure. html#weeks: A week begins on Sunday, not on Monday. Not according to ISO [1] [1] http://en.wikipedia.org/wiki/ISO_week_date
Re: [whatwg] [html5] Pre-Last Call Comments
On Sun, Apr 5, 2009 at 9:04 AM, Giovanni Campagna scampa.giova...@gmail.com wrote: A few comments, as requested by Ian Hickson. [...] - In section 3.3.3.7, instead of defining the syntax of style attributes, reference http://www.w3.org/TR/css-style-attr The style property has been part of the HTMLElement interrface for many years. Reading ahead, I see this has been addressed. It would be useful to have a few others: computedStyle cascadedStyle getStyleValueAs(prop, unit); The computedStyle is already possible, just clunky. A cascadedStyle doesn't exist. getStyleValueAs exists as a very clunky API that doesn't work in browsers. Garrett
Re: [whatwg] [html5] Pre-Last Call Comments
It is possible to create no-script fallback without a NOSCRIPT element. You can put it into d...@class=noscript] and remove the DIV at run time. It is worth noting that XHTML 1.0, along with deprecating MAP/@name, still has the unrealistic assumption about usemap containing an arbitrary URI. I would not put much weight to that. Cheers, Chris
[whatwg] [html5] Pre-Last Call Comments
A few comments, as requested by Ian Hickson.
- End of 2.2.1, a typo: JavsScript instead of Javascript
- From section 2.4.2 I don't understand if boolean attributes with
invalid values represent true or false. In addition, I don't
understand if an empty value is false (as in XHTML1.0) or true (as in
HTML4, because of the minimized syntax).
From my experience, I expect that the empty string (which is
equivalent to not specify the attribute at all) is false, and any
other value is true.
- In 2.4.3 I don't see the point of all the digression about
contentEditable, since it is noted that it doesn't work like that. I
would leave the note to just Note: The empty string can be one of the
keywords or Note: The empty string can a valid keyword
- In 2.4.4.3 (and maybe in other places) I would prefer [A|E]BNF
instead of the prose description of a floating point number. I'm also
not sure that the normative algorithm is needed.
I've also searched IEEE, IETF, ECMA, ISO and ANSI for another
normative version of the syntax and processing, but I've found none.
If you think that it is important to have it specified completely, you
may submit an ID, so future technologies won't need to rewrite it
again.
- The second paragraph in 2.4.5.6 is hard to understand because the
verb is at the end. I would rewrite as A week-year with a number *yr*
has 53 weeks if corresponds to a year *yr* in the proleptic Gregorian
calendar that has a Thursday as its first day (January 1st), or if
*yr* where *yr* is a number divisible by 400, or a number divisible by
4 but not by 100. In all other cases it has 52 weeks
Also, don't rely on styles alone, use different words for identifiers
and prose. This includes also the Note following, where no styles are
applied and it is difficult to understand that year year is not a
typo but rather is the year numbered year.
- Can't be simply referenced CSS3 Color in 2.4.6?
This way, implementors could have body[bgcolor] { background-color:
attr(bgcolor,color,white); } in the default CSS instead of using HTML5
specific rules.
- In 2.4.9 a valid hash reference must be equal to an ID, name is
supported only for backward compatibility.
- No comments for the URL part (except that Web Addresses is different
in processing, and the proposed IRI-bis draft makes it unnecessary)
- Section 2.6 is superfluous: handling of application cache is
specified in the appropriate section, handling of HTTP requests and
caches is defined in RFC2616, handling of cookie is defined in the
appropriate RFC (I don't remember the number), handling of about:blank
is in the proposed about-uri-scheme ID.
In addition, serialized queue-based handling of resources should not
be mandated by the HTML5 specification (can't UAs be multi-threaded?)
- Rewriting 2.6.1 without the HTTP word is definitely better. Browsers
are not required to support HTTP, AFAIK. You can write a GET method
(because GET is anyway an English word), a response code (most
protocols have response codes) and metadata (instead of headers,
that SMTP, POP, FTP don't support)
- 2.6.2 should be implied by the HTTP-over-TLS RFC
- In section 2.7.1, in sentence Extensions must not be used for
determining resource types for resources fetched over HTTP., do you
mean File extensions, like .txt or .png, or User agent extensions
(additions to the algorithm)?
- Still in section 2.7.1, why the algorithm is a violation of RFC2616?
Because it is case insensitive? Because it allows spaces? Because it
does not imply ISO-8859-1 if no charset is explicit? Because it does
not imply ASCII for text/* mime types?
- Why don't you add ?xml to the sniffing table?
- In section 2.8, x-x-big5 is not a different encoding than big5,
it rather seems an alias (and as such should be submitted to IANA)
- Later in the same section, I don't understand why you don't support
those encodings, if the encoding declaration is explicit in the
protocol layer or is allowed by a different specification. For
example, XML allows EBDIC based encodings. In addition, I don't
understand why supporting UTF-32 or EBDIC means a change to the
algorithm, that are defined in terms of Unicode code points (very
similar to UTF-32 characters)
- In section 2.9.1, I completely don't understand the part about DOM
attributes of type HTMLElement, especially the subpart about setting.
- In section 2.9.5, instead of define DOMStringMap only for
EcmaScript, use explicit indexing operation in the IDL, add them the
[NameGetter] / [NameSetter] / [NameDeleter] attributes, and add a
[NoIndexingOperation] to the whole interface.
- In section 2.9.6 you discourage use of hasFeature. Firstly, if an
implementation says true and it is not compliant, it is not a spec
bug, it is an implementation bug. Secondly, to allow implementation
granularity, you could define more features (for example HTML 5.0,
XHTML 5.0, HTMLCanvas2D 5.0, HTMLSection 5.0, HTMLDatagrid 5.0,
HTMLMediaObject 5.0 etc.)
- In section 3.2.1, seems that interfaces other than
Re: [whatwg] [html5] Pre-Last Call Comments
Character set x-x-big5 cannot be registered because it is private. Now that classid is gone, what will be the workaround for ActiveX objects where they are needed? 1. Ask Windows browsers to support Type=application/x-oleobject;classid=...? 2. Use a custom DTD with classid for validation? 3. Use a custom type application/vnd.acme-fancy-control+oleobject for every control? 4. Rewrite everything Silverlight? 5. Ask the developers to keep their pages HTML4? Of course, such things are inherently nonportable but they are widely used. It would be nice to have a way to validate them. Chris
Re: [whatwg] [html5] Pre-Last Call Comments
On , Kristof Zelechovski giecr...@stegny.2a.pl wrote: Character set x-x-big5 cannot be registered because it is private. Now that classid is gone, what will be the workaround for ActiveX objects where they are needed? classid is nevertheless proprietary, and no other user agent but IE will require it (unless others implement ActiveX as well). The spec does not forbid to use non supported attributes and elements. It only specifies the handling for the known ones.
Re: [whatwg] [html5] Pre-Last Call Comments
The specification forbids the authors using undefined elements and attributes; a document containing classid will not be valid. Still, the site hosting the controls will need a way to test validity of pages for QA. Chris
Re: [whatwg] [html5] Pre-Last Call Comments
Giovanni Campagna:
- The second paragraph in 2.4.5.6 is hard to understand because the
verb is at the end. I would rewrite as
A week-year with a number *yr* has 53 weeks if corresponds to a
year *yr* in the proleptic Gregorian calendar that has a Thursday
as its first day (January 1st), or if *yr* where *yr* is a number
divisible by 400, or a number divisible by 4 but not by 100. In all
other cases it has 52 weeks
| A week-year with a number $year that corresponds to a year $year in
the
| proleptic Gregorian calendar that has a Thursday as its first day
| (January 1st), and a week-year $year where $year is a number divisible
| by 400, or a number divisible by 4 but not by 100, has 53 weeks. All
| other week-years have 52 weeks.
The description is wrong anyhow: Not every leap year has 53 weeks!
(For instance, 2008 and 2012 have 52 weeks only.) The difference to
common years is that leap years with 53 weeks can have Jan01 on
either Thu or Wed, because Dec31 then is Fri or Thu respectively.
(Compare your 2020 to your 2004 calendar.)
: A week-year has 52 weeks, except it has 53 weeks when 1 January in the
: Gregorian year of the corresponding number $year falls on a Thursday,
: or it falls on a Wednesday and $year is a leap year.
1 January = the first day of the first month (-01-01, -001)
a Thursday = the fourth day of the week (-4)
a Wednesday = the third day of the week (-3)
leap year = number divisible by 4 but not by 100 or a number
divisible by 400
Or just reference and rely on ISO 8601. That is what references
(especially to standards) are for after all.
By the way, because there is an even number of weeks in a Gregorian
400-year cycle, the 53-week years (after the epoch) are:
400 * n + a; n e |N°, a c L
L := {004, 009, 015, 020, 026, 032, 037, 043, 048, 054, 060, 065,
071, 076, 082, 088, 093, 099, 105, 111, 116, 122, 128, 133,
139, 144, 150, 156, 161, 167, 172, 184, 189, 195, 201, 207,
212, 218, 224, 229, 235, 240, 246, 252, 257, 263, 268, 274,
280, 285, 291, 296, 303, 304, 308, 314, 320, 325, 331, 336,
342, 348, 353, 359, 364, 370, 376, 381, 387, 392, 398}
That is 71 leap-week years opposed to 97 leap-day years.
PS: All complications are the fault of the month calendar, not of the
week calendar.
