On Mar 11, 2007, at 4:39 AM, Mihai Sucan wrote:
It's false to assume the UA developers can happily say now we'll
parse HTML5, lets use our new HTML5 parser. No, this won't happen.
Here's why: the UA cannot be sure that the document is *really*
HTML 5.
Browsers don't read DTDs. They
On Mon, 12 Mar 2007, olivier Thereaux wrote:
Did you have a chance to look at engines in authoring tools? What type of
parser do NVU
Gecko, same as Firefox.
Amaya,
Amaya's editor uses the same rendering engine as Amaya's browser, which I
presume was ignored due to its negligible market
On Sun, 11 Mar 2007 22:47:36 +0100, carmen [EMAIL PROTECTED] wrote:
thats kind of what i'm asking, it looks like SVG has its own API
already, sort of similar to canvas. are there plans to merge? can you
use svg elements inwide a canvas element or will the browser not find
them? are there
Hi all.
My apologies for starting this rather exciting thread. :)
Several commenters (Matthew Raymond comes most prominently to mind) have
convinced me that while a global href attribute would be handy, it's
just not worth it:
One of his excellent points is a real clincher for me:
Daniel
Hi all. (Double apologies for accidentally sending that last email
before finishing it)
My apologies for starting this rather exciting thread. :)
Several commenters (Matthew Raymond comes most prominently to mind) have
convinced me that while a global href attribute would be handy, it's
On Sun, March 11, 2007 7:57 pm, Ian Hickson wrote:
The Web has done great so far without it? When strict mode was
introduced, all existing websites didn't suddenly start rendering under
it. It was opt-in. Versioning is just a formalized way of opting into
a certain rendering method.
On 12 Mar 2007, at 17:39, Ian Hickson wrote:
Any reasonable implementation would have a base rendering engine and
then browser differences would extend off of it. A new version would
mean you change only what differs between versions.
You still end up with dozens of codepaths to test.
On Mon, March 12, 2007 10:39 am, Ian Hickson wrote:
It's tempting to think that browser makers will get it right the first
time, but I'm not sure I believe it. !DOCTYPE HTML might introduce
headaches when Microsoft or Mozilla or somebody realize they've had a
bug in their rendering engine for
The recent discussion of possibly making the href attribute global
brings to mind a broader issue. To what extent should semantics and
behavior belong to specific elements, and to what extent should they
be carried by global attributes that can apply to any element?
XHTML2 moves a lot
On Mar 11, 2007, at 1:34 PM, carmen wrote:
suppose one is building a GUI with solely canvas elements.
i suppose i should have researched canvas - it looks like it
doesn't have elemnts one might be faimilar with the Tk canvas - you
can only draw using javascript. are there plans to
On Mon, 12 Mar 2007, Matthew Ratzloff wrote:
On Mon, March 12, 2007 10:39 am, Ian Hickson wrote:
It's tempting to think that browser makers will get it right the
first time, but I'm not sure I believe it. !DOCTYPE HTML might
introduce headaches when Microsoft or Mozilla or somebody
- Original Message -
From: Maciej Stachowiak [EMAIL PROTECTED]
To: WHATWG Mailing List [EMAIL PROTECTED]
Sent: Monday, March 12, 2007 10:25 AM
Subject: [whatwg] Attributes vs. Elements
|
|
| The recent discussion of possibly making the href attribute global
| brings to mind a
XHTML2 moves a lot of semantics and behavior from elements to global
attributes. For example, href can turn any element into a hyperlink,
and src can turn any element into an image.
I liked the href adding a link to any object, but the src, I don't care
for. I can already set a background
Finally, I'd like to conclude with this reductio ad absurdum of the XHTML2
approach. If assigning behavior and semantics to attributes is so much
better, why not just have a single elt element:
elt role=paragraphMy cat is really cute: elt src=mycat.jpegpicture of
my cat/elt. Check out
On 12 Mar 2007, at 20:19, Andrew Fedoniouk wrote:
Case:
td a href=1.htmxyz/a/td
td a href=2.htmxyz-xyz-xyz/a/td
is perfectly valid from some abstract semantic machine
point of view but for human these two cells are not
equal. At least hit area is different. And visual perception too.
All you
On Mon, 12 Mar 2007, carmen wrote:
Finally, I'd like to conclude with this reductio ad absurdum of the
XHTML2 approach. If assigning behavior and semantics to attributes is
so much better, why not just have a single elt element:
elt role=paragraphMy cat is really cute: elt
Maciej wrote:
canvas is a programmatic immediate mode drawing surface. For
retained-mode structured graphics, SVG would be your solution. Both
things are useful.
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
[EMAIL PROTECTED] wrote:
Those who have worked with Canvas for the past several years have
probably written documents somewhere to explain just why the two specs
(SVG and Canvas) should not be merged. If someone could point me toward
that rationale, I will emerge enlightened and grateful
On 12 Mar 2007, at 20:19, Andrew Fedoniouk wrote:
Case:
td a href=1.htmxyz/a/td
td a href=2.htmxyz-xyz-xyz/a/td
is perfectly valid from some abstract semantic machine
point of view but for human these two cells are not
equal. At least hit area is different. And visual perception too.
All you
There is nothing to stop browser developers using the same underlying
implementation for canvas and svg rendering, so the overlap in
function becomes a plus point from a programming point of view.
Until either Canvas or SVG become completely available there will be
a place for both.
Robert wrote:
As I followed the thread, thinking about styling the element was the
clincher for me. IE 6 doesn't support attribute based selectors. So, I,
for one, couldn't use it until IE 6 (haven't tested attribute selectors in
IE 7, since I stopped using them in light of IE 6) lost most of
On Mon, March 12, 2007 3:34 pm, ddailey wrote:
Those who have worked with Canvas for the past several years have probably
written documents somewhere to explain just why the two specs (SVG and
Canvas) should not be merged. If someone could point me toward that
rationale, I will emerge
- Original Message -
From: Nicholas Shanks [EMAIL PROTECTED]
To: Andrew Fedoniouk [EMAIL PROTECTED]
Cc: WHATWG List [EMAIL PROTECTED]
Sent: Monday, March 12, 2007 12:59 PM
Subject: Re: [whatwg] Attributes vs. Elements
| On 12 Mar 2007, at 20:19, Andrew Fedoniouk wrote:
|
| Case:
|
From: Gareth Hay wrote
There is nothing to stop browser developers using the same underlying
implementation for canvas and svg rendering, so the overlap in function
becomes a plus point from a programming point of view.
Good point. I guess the difficulty is not really in parsing the markup,
How do you define style for datagrids?
e.g.
- row color
- alternating row color
- selected row color
- initial column widths
- fixed column widths
On Tue, 13 Mar 2007, Sean Hogan wrote:
How do you define style for datagrids?
e.g.
- row color
- alternating row color
- selected row color
- initial column widths
- fixed column widths
The plan is to introduce some pseudo-elements in the rendering section.
However, this will require
ddailey wrote:
The ease of using DOM methods to find tags, as opposed to attributes,
tends to suggest that all things having href's should be easily
findable by script. a works nicely for that, but would the
availability of a document.links array then include all things with
href's?
In
Edward O'Connor wrote:
Please excuse the analogy, but try thinking about it this way: canvas is
to Photoshop as SVG is to Illustrator.
I think it's a bit more elusive than that. SVG allows bitmaps to be
imported, and subsequently filtered (blurs, displacements, channel
separations, layers,
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 behavior. But I don't
Edward O'Connor wrote:
Please excuse the analogy, but try thinking about it this way: canvas is
to Photoshop as SVG is to Illustrator.
No, not really. canvas is to Illustrator as JPEG is to Photoshop. SVG
is also to Illustrator as JPEG is to Photoshop.
It's more like canvas is to
On 3/12/07, Maciej Stachowiak [EMAIL PROTECTED] wrote:
object data=about:blank
bfallback/b
script
alert('y');
/script
/object
I asked about this a while ago. Here's the old discussion:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-May/006365.html
X 10.4). I took your suggestion and ran the tests on my rented
virtual server.
To see the results (explanations of each are on the page):
[1] http://whatwg.robertdot.org/files/20070312-html/
[2] http://whatwg.robertdot.org/files/20070312-xhtml/
Also, I added the following to an .htaccess
On 12/03/2007 21:53, [EMAIL PROTECTED] wrote:
XHTML2 moves a lot of semantics and behavior from elements to global
attributes. For example, href can turn any element into a hyperlink,
and src can turn any element into an image.
I liked the href adding a link to any object, but the src, I
Le 13 mars 2007 à 03:25, Maciej Stachowiak a écrit :
The recent discussion of possibly making the href attribute global
brings to mind a broader issue. To what extent should semantics and
behavior belong to specific elements, and to what extent should
they be carried by global attributes
On 13/03/2007 07:12, Karl Dubost wrote:
more references, food for thoughts.
* Markup design: elements or attributes?
http://annevankesteren.nl/2004/07/markup
* Principles of XML design: When to use elements versus attributes
http://www-128.ibm.com/developerworks/xml/library/x-eleatt.html
On Tue, 13 Mar 2007, Daniel Glazman wrote:
I would add a major principle, rarely explicit : PRAGMATISM. Sometimes
purity calls for an element while browser implems call for an attribute
; or the contrary. And even if implem issues should not apply in theory,
they do apply in real life...
Le 13 mars 2007 à 15:23, Daniel Glazman a écrit :
I would add a major principle, rarely explicit : PRAGMATISM.
Sometimes purity calls for an element while browser implems
call for an attribute ; or the contrary. And even if implem
issues should not apply in theory, they do apply in real life...
On 13/03/2007 07:26, Ian Hickson wrote:
Don't worry, the WHATWG basic principles put pragmatism first. It's the
only way to get a spec implemented, and without implementations, specs are
somewhat academic.
It's also the only way to do something not totally disconnected from
users' needs...
On 13/03/2007 07:29, Karl Dubost wrote:
It comes with test cases and implementations.
I disagree 100%. Pragmatism is a state of mind, not a process.
Tests and implementations can be successful on a spec, and the spec
can remain a failure because it lacks pragmatism.
/Daniel
39 matches
Mail list logo
