Re: [whatwg] cross-domain scrollIntoView on frames and iframes
On Sun, Apr 5, 2009 at 1:09 AM, Giorgio Maone wrote: > It would make clickjacking attacks more precise, by exactly positioning the > frame content where the attacker wants it to be. > Not that you cannot already be pixel-precise by using absolute positioning > inside an overflow: hidden div... > Let's say it would make them even more script-kiddies friendly. Hum... That doesn't sound that bad. If you're relying on the obscurity of pixel offsets for a clickjacking defense, then you've got bigger problems than scrollIntoView. Adam
[whatwg] Start position of media resources
Ogg based media resources can start from a time position that is not zero. Examples of files that do this are those generated by the program oggz-chop. For example: http://ia331342.us.archive.org/2/items/night_of_the_living_dead/night_of_the_living_dead.ogv?t=0:20:00/0:20:50 If this is played in VLC the start time of the video is 0:20:00. When seeking the time requested for the seek must be between 0:20:00 and 0:20:50. Does the HTML5 spec allow media resources that don't start from 0? I see in the spec mention: "Media elements have a current playback position, which must initially be zero. The current position is a time." In the case of the Ogg file above, the current playback position would initially be zero, but when the first frame is loaded it will be 0:20:00. Is this valid per the spec? If so, would we need an attribute on the media object so the web page author can retrieve the start time of the video (in the same way they can get the duration). They would need this to be able to display progress bars/scrubbers to position the thumb correctly based on the currentTime. Detecting the first frame or metadata loaded events and getting the position of the that won't work as some of the video may have been played by the time that event is handled by user code. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] HTML5 typos
On Sun, Apr 5, 2009 at 3:44 PM, Kartikaya Gupta wrote: > Also, the following words appear with different spelling variations; I > suggest one of the variants be picked and used consistently: > > behaviour vs. behavior > favorite vs. favourite > honour vs. honor > occurance[s] vs. occurrence[s] This isn't a variation. As far as I'm aware, "occurance", "occurance", and "occurence" are not considered valid spellings by anyone: the correct spelling is "occurrence".
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.
[whatwg] HTML5 typos
I ran the spec through a typo-finder program I cooked up and it found these among lots of false positives. altogther (4.8.2.1.13) approprate (5.8.4) argments (4.8.11.1.10) asychronously (5.8.4) attribue's (2 in 4.6.12) attrbutes (4.10.4) constaints (4.10.14.2, 2 in 4.10.14.3) elemnt (4.10.14.3) elment (6.5, 4.3.1) follwed (4.10.2) fouth (4.10.9) implementaion (5.7.2) indicies (4.10.1, 4.10.6) knowns (4.2.2) oherwise (3.3.3.5) snipet (4.6.10) sebsteps (5.8.4) Also, the following words appear with different spelling variations; I suggest one of the variants be picked and used consistently: behaviour vs. behavior favorite vs. favourite honour vs. honor occurance[s] vs. occurrence[s] categoris* vs. categoriz* recognis* vs. recogniz* serialis* vs. serializ* tokenis* vs. tokeniz* Cheers, kats
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
On , Kristof Zelechovski 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
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
[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 "http://www.w3.org/TR/css-style-attr>
- In section 4.2.5.3, a document may have a default language even if
it doesn't have a content-language http-equiv, if it has a
Content-Language HTTP header.
- Section 4.2.7 should be completely delegated to CSSOM
- Noscript should be allowed in XML, just without the complexity (and
simply treated as display:none if scripting is enabled)
- And is a grammar mistake in "These juicy, green apples and make a
great filling for
apple pies" (the example in 4.4.2)
- I completely cannot understand 4.4.10.2
- I would like to disagree with the man who disagreed with the other
man who disagreed with Ian Hickson (who said that things that are
impossible just take longer) (section about )
- I don't think it is of any use to link a BBC article in 4.6.20
- Section 4.8.3 still refers to the Window Object specification, which
I think has been superseded by HTML5
- classid is not a conforming attribute for object, and yet it is used
in the algorithm to find a plugin. AFAIK, classid is only used by IE
(along with COM) so I don't think it is a problem to drop it
completely.
(skipping video and canvas)
- in HTMLFormElement, the function item should accept an integer, not
a DOMString (because it is an IndexGetter) Same in HTMLSelectElement
- In section 4.10.4, the table about which attributes applies to the
