Re: [whatwg] cross-domain scrollIntoView on frames and iframes
Peter Kasting wrote, On 05/04/2009 0.54: On Sat, Apr 4, 2009 at 12:56 PM, timeless timel...@gmail.com wrote: sounds like a security nightmare. Can you be less vague? We've had a number of security people vet this already, so specific complaints would be very helpful. PK 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. -- Giorgio Maone
[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
[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
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.
Re: [whatwg] HTML5 typos
On Sun, Apr 5, 2009 at 3:44 PM, Kartikaya Gupta lists.wha...@stakface.com 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.
[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] cross-domain scrollIntoView on frames and iframes
On Sun, Apr 5, 2009 at 1:09 AM, Giorgio Maone g.ma...@informaction.com 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
