Maciej Stachowiak wrote:
As far as I can tell, the current spec does not adequately define how
fallback behavior works. Specifically, what should be done with fallback
content when not falling back?
Presumably it should be parsed into the DOM, but should not render -
that's the de facto
On Tue, 13 Mar 2007 00:47:23 +0100, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
As far as I can tell, the current spec does not adequately define how
fallback behavior works. Specifically, what should be done with fallback
content when not falling back?
Presumably it should be parsed into
On Mar 13, 2007, at 1:46 AM, Anne van Kesteren wrote:
On Tue, 13 Mar 2007 00:47:23 +0100, Maciej Stachowiak
[EMAIL PROTECTED] wrote:
As far as I can tell, the current spec does not adequately define
how fallback behavior works. Specifically, what should be done
with fallback content when
On Tue, 13 Mar 2007 11:28:36 +0100, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
As far as I can tell, the current spec does not adequately define how
fallback behavior works. Specifically, what should be done with
fallback content when not falling back?
Presumably it should be parsed into
Le Tue, 13 Mar 2007 13:21:14 +0200, Anne van Kesteren [EMAIL PROTECTED] a
écrit:
Not sure. Should
object data=foo
img src=bar onload=alert('x')
show a modal dialog?
No, it should not. Fallback content should not execute (styling and
scripts), also, fallback content should not be
Hi list,
Implementing a new web application from scratch, I found out some new
ideas to make the appearance of site better. I'm not sure here are
the best place for this discussion, but at least it's not out of
interest.
First one is how Mozilla/Firefox do the zooming thing, Text Size.
On web
Behnam ZWNJ Esfahbod wrote:
The second one is to get the web server decide which image file is
better. An Apache httpd module can select the best response for a
request for image the-company-logo if it knows which size is needed,
and what mime-types are acceptable.
My idea is to add a field to
Gervase Markham wrote:
Behnam ZWNJ Esfahbod wrote:
This is SO overkill. This should be handled by the user agent.
Actually some already do. Opera has done that for years, and IE7 is
close but fall short by not zooming the background images.
The second one is to get the web server decide
On Fri, 09 Mar 2007 23:46:15 +0100, Alexey Feldgendler
[EMAIL PROTECTED] wrote:
There would be replies if your idea was incomplete or controversial, but
actually it seems like everyone agrees.
Well, I'm not so sure. I'm hoping for some debating! :)
What worries me is whether there is a
On Sat, 10 Mar 2007 11:16:09 +0100, Mihai Sucan [EMAIL PROTECTED]
wrote:
Alexey, actually I'm skeptical about this. First impression I had
reading the first post was hey, do we need yet another switch?. What's
super-duper standards mode after all?
It's something Internet Explorer needs
At the risk of killing beautiful simplicity, can we consider amending
this to
!DOCTYPE html5
or something similar? The omission of a version number feels like
playing with fire to me.
Colin Lieberman
3. For super-duper standards mode use the following DOCTYPE:
!DOCTYPE html
On 13/03/2007 16:51, Colin Lieberman wrote:
At the risk of killing beautiful simplicity, can we consider amending
this to
!DOCTYPE html5
or something similar? The omission of a version number feels like
playing with fire to me.
Hum to say the least. One of the goals of the WHAT-WG is the
I'm not sure how this is a backwards compatibility issue. My
understanding is that user agents aren't actually parsing information
from the doctype, just checking for its existence. The only applications
that should break are validators, which would need to be updated anyway.
I ran some quick
On Tue, 13 Mar 2007 17:04:39 +0100, Colin Lieberman [EMAIL PROTECTED]
wrote:
I'm not sure how this is a backwards compatibility issue. My
understanding is that user agents aren't actually parsing information
from the doctype, just checking for its existence. The only applications
that
On 12/03/07, ddailey [EMAIL PROTECTED] wrote:
I would like to believe that Canvas is useful, but being both naive and
stubborn, I don't yet see why.
In reading through the WHATWG draft, there are about N things that it seems
to be talking about. I see N-2 of those as redundant with the SVG
Le Tue, 13 Mar 2007 18:04:39 +0200, Colin Lieberman [EMAIL PROTECTED] a
écrit:
I'm not sure how this is a backwards compatibility issue. My
understanding is that user agents aren't actually parsing information
from the doctype, just checking for its existence. The only applications
that
Asbjørn Ulsberg wrote:
Well, I'm not so sure. I'm hoping for some debating! :)
Looks like you got your wish. This thread has been popular.
Considering that Chris Wilson is the chair of the HTML WG as well as the
Platform Architect on the IE crew, plus the fact that several members
of
Currently in HTML 4, and apparently in Web Forms 2, there is a rule that
each label element applies to exactly one input field. 10 inputs, at
least 10 labels.
However looking at a number of tabular but not exactly repeating forms,
both on the Web and on paper, I notice that it common for the
In WF2 I can prefill a select list with external data pointed to by a
data attribute like so:
form
labelChoose the species:
select name=species data='examples/species.xhtml'/select
/label
labelinput type=submit value=Send data //label/p
/form
However it strikes me as funny that I can't
On Tue, 13 Mar 2007 18:37:31 +0100, Elliotte Harold
[EMAIL PROTECTED] wrote:
Currently in HTML 4, and apparently in Web Forms 2, there is a rule that
each label element applies to exactly one input field. 10 inputs, at
least 10 labels.
However looking at a number of tabular but not
Elliotte Harold wrote:
What strikes me about examples like this is that the labels for the
input fields naturally apply to more than one input field.
I think the main problem with multiple IDs for labels is the usability.
How would it work and still make sense?
You could, instead, have
On Tue, 06 Mar 2007 21:38:59 +0100, Simon Pieters [EMAIL PROTECTED]
wrote:
They don't conflict. They are both applied. base is the document's
base URI, and xml:base is the base URI of the element it is applied on.
What about:
base href=http://www.example.org/; xml:base=/bar /
?
--
Elliotte Harold wrote:
However it strikes me as funny that I can't prefill a repeating form. e.g.
div id=observation repeat=template
labelSpecies:
input type=text name=species[observation].name
data=http://www.example.com/values.html/
/label
/div
I could be wrong but
Robert Brodrecht wrote:
Elliotte Harold wrote:
What strikes me about examples like this is that the labels for the
input fields naturally apply to more than one input field.
I think the main problem with multiple IDs for labels is the usability.
How would it work and still make sense?
Le 2007-03-13 à 13:37, Elliotte Harold a écrit :
Homework 1 Homework 2 Homework 3
John Smith87 86 98
Jane Jones 100 78 98
Fred Wilde89 65 69
My opinion is that the table itself, given headers are properly
marked up
On Sat, 10 Mar 2007 12:26:12 +0100, Keryx Web [EMAIL PROTECTED] wrote:
Personally I think the best route to go for MS is to fix all bugs and
make Standards Compliance Mode truly compliant. And perhaps mimic FFox
and have an almost compliance mode for transitional doctypes, behaving
the
Elliotte Harold wrote:
Pretty much like it does now I suspect. When presenting the form control
to a user, the software would assign it the label. It would just use
the same label more than once.
The for attribute is not new. What's being proposed is simply allowing
it to identify
Robert Brodrecht wrote:
I think the main problem with multiple IDs for labels is the
usability. How would it work and still make sense?
Elliotte Harold replied:
Pretty much like it does now I suspect. When presenting the form
control to a user, the software would assign it the label. It
Michel Fortin wrote:
My opinion is that the table itself, given headers are properly marked
up with th, provides enough information to make the labels unnecessary.
I'll second this. Given that the table is marked up correctly (that is,
using th and |scope| or equivalents), it should be usable
On Sat, 10 Mar 2007 14:41:15 +0100, Mihai Sucan [EMAIL PROTECTED]
wrote:
So, with each new version of IE (released every 5-10 years), we will have
a new DOCTYPE, and a new rendering mode?
No. Internet Explorer hasn't implemented (at least that I am aware of) any
proprietary or broken
On Sat, 10 Mar 2007 14:43:44 +0100, Elliotte Harold
[EMAIL PROTECTED] wrote:
What are those of us who wish to use XML tools on our documents supposed
to use?
Set the 'xml_tool.ignore_doctype' property to 'true'. I'm sure most XML
libraries have this (or a similar) option. At least most
* Asbjørn Ulsberg wrote:
No. Internet Explorer hasn't implemented (at least that I am aware of)
any proprietary or broken stuff in their browser for over 7 years.
No, IE7 introduces for example the -ms-interpolation-mode CSS property.
There is of course little wrong with that.
--
Björn Höhrmann
On Sat, 10 Mar 2007 21:51:14 +0100, Shadow2531 [EMAIL PROTECTED]
wrote:
You make a good point. It could very well be an endless loop and
there's no guarantee (or even past evidience to show) that IE's new
standards mode would be up to par.
Yes, but only time will tell. If Microsoft
Le Tue, 13 Mar 2007 19:37:31 +0200, Elliotte Harold
[EMAIL PROTECTED] a écrit:
However looking at a number of tabular but not exactly repeating forms,
both on the Web and on paper, I notice that it common for the column
headers to essentially serve as label for the input fields. For
Many pages use tables where only the first column are header cells, e.g.:
table
trthFoo tdBar
trthFoo tdBar
trthFoo tdBar
/table
With the current algorithm for assigning header cells to data cells, the
first th won't be a header cell for any data cells. In order to be more
On Tue, 13 Mar 2007 18:37:31 +0100, Elliotte Harold
[EMAIL PROTECTED] wrote:
Homework 1 Homework 2 Homework 3
John Smith87 86 98
Jane Jones 100 78 98
Fred Wilde89 65 69
I'd mark this up as follows:
table
On Tue, 13 Mar 2007 20:32:33 +0100, Bjoern Hoehrmann [EMAIL PROTECTED]
wrote:
No. Internet Explorer hasn't implemented (at least that I am aware of)
any proprietary or broken stuff in their browser for over 7 years.
No, IE7 introduces for example the -ms-interpolation-mode CSS property.
On Tue, 13 Mar 2007, Elliotte Harold wrote:
In WF2 I can prefill a select list with external data pointed to by a data
attribute like so:
form
labelChoose the species:
select name=species data='examples/species.xhtml'/select
/label
labelinput type=submit value=Send data //label/p
On Tue, 13 Mar 2007 21:07:20 +0100, Simon Pieters [EMAIL PROTECTED]
wrote:
Many pages use tables where only the first column are header cells, e.g.:
table
trthFoo tdBar
trthFoo tdBar
trthFoo tdBar
/table
With the current algorithm for assigning header cells to data
On Tue, 13 Mar 2007 19:15:12 +0100, Asbjørn Ulsberg
[EMAIL PROTECTED] wrote:
On Tue, 06 Mar 2007 21:38:59 +0100, Simon Pieters [EMAIL PROTECTED]
wrote:
They don't conflict. They are both applied. base is the document's
base URI, and xml:base is the base URI of the element it is applied
What about:
base href=http://www.example.org/; xml:base=/bar /
?
Then the document's base URI is http://www.example.org/ and the base
element's base URI is http://www.example.org/bar.
I'm not entirely sure this is legal but what about (say for a document on
http://localhost/):
Asbjørn Ulsberg Wrote:
I did not think that @profile could be used as a rendering mode switch,
I didn't mean to suggest this was your line of thought. What the IE team
uses as a switch is arbitrary. I'm doing my best to keep the versioning
stuff I mentioned before inline with the topic of the
On Tue, 13 Mar 2007 21:29:09 +0100, Asbjørn Ulsberg
[EMAIL PROTECTED] wrote:
On Tue, 13 Mar 2007 21:07:20 +0100, Simon Pieters [EMAIL PROTECTED]
wrote:
Many pages use tables where only the first column are header cells,
e.g.:
table
trthFoo tdBar
trthFoo tdBar
trthFoo
On Tue, 13 Mar 2007 20:02:10 +0100, Asbjørn Ulsberg
[EMAIL PROTECTED] wrote:
The only way to not break 50% of the web is to invent a new mode that
gives the IE developers a blank sheet they can begin to draw on.
FWIW, I think the 50% figure is incorrect. According to [1], 90% of the
web
Ian Hickson wrote:
If you're trying to prefixx a _form_, then
you do that at the form level, and the spec describes how it works for
repetition fields. I have no idea what you would mean by a data
attribute on an input element, though.
The piece I thought muyst exist did. It was section
On Tue, 13 Mar 2007 20:29:09 -, Asbjørn Ulsberg
[EMAIL PROTECTED] wrote:
Many pages use tables where only the first column are header cells,
e.g.:
table
trthFoo tdBar
trthFoo tdBar
trthFoo tdBar
/table
With the current algorithm for assigning header cells to
On 3/13/07, Asbjørn Ulsberg [EMAIL PROTECTED] wrote:
On Sat, 10 Mar 2007 21:51:14 +0100, Shadow2531 [EMAIL PROTECTED]
wrote:
I guess at the least, it shows the desperate need to do something about
IE.
I actually think the problem lies within Microsoft itself. I recommend
reading the following
Hi Ian,
Thank you for the insightful comments and information about parsers.
On Mar 12, 2007, at 16:21 , Ian Hickson wrote:
Why do you think search engine behaviour is more important than
browser
engine behaviour? For what it's worth, search engine engineers I have
spoken to have told me that
Hi,
The spec currently defines most embedding elements (img, iframe,
embed, object, video and canvas) as strictly inline level and thus only
allows them to be used in contexts where strictly inline level content
may be used.
I think these elements should be defined as structured
- Original Message -
From: Lachlan Hunt [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, March 13, 2007 9:23 PM
Subject: [whatwg] Embedding Elements Should be Structured Inline-Level
Hi,
The spec currently defines most embedding elements (img, iframe, embed,
object, video
50 matches
Mail list logo
