Just a barely relevant observation for the moment: CSS selectors
really ought to be their own language, separate from CSS spec. Kind of
like XPATH/XSLT relationship.
I am running with the microformats crowd (or should I say herd :)
occasionally, and the CSS selectors are a great fit for searching
Doh! :)
Are there any languages at the moment that utilize Selectors other than CSS?
:DG
On 9/30/05, Ian Hickson [EMAIL PROTECTED] wrote:
On Fri, 30 Sep 2005, Dimitri Glazkov wrote:
Just a barely relevant observation for the moment: CSS selectors
really ought to be their own language
On 8/24/05, Ian Hickson [EMAIL PROTECTED] wrote:
On Tue, 23 Aug 2005, Dimitri Glazkov wrote:
Ian, I think the opposite is true, actually. Most of the browser-based
HTML editors that I saw operate by augmenting functionality of a
textarea element, and the accept attribute would work make
I've been following this thread for a little while. I too think that
the contentEditable is not done quite right.
My biggest problem with it (and this was pointed out before) is that
it is a half-way effort: there is markup that enables the editing, but
there is no markup that provides any
On 8/23/05, Ian Hickson [EMAIL PROTECTED] wrote:
On Tue, 23 Aug 2005, Hallvord Reiar Michaelsen Steen wrote:
Could we extend contentEditable in a way that would let the UA offer a
non-scripting UI for saving the edited page? For example using the
form attribute from WF2?
What's wrong
On 8/23/05, Ian Hickson [EMAIL PROTECTED] wrote:
Actually, originally, HTML was supposed to be user editable always. Much
like in Amaya. So contentEditable is more of a compromise between the
original intent of the Web and the don't let them modify it! attitude
that has grown since.
I
I may have spoken too soon on the absence of rich text editing textarea in WF2.
Looking at the spec, there is an accept attribute for the textarea
element, and its description fits the bill very nicely. If we have
accept=text/html or accept=application/xml+xhtml, it is totally up
to the UA to
On 7/19/05, Ian Hickson [EMAIL PROTECTED] wrote:
@media {
navigation { display: none; }
}
Ok, at least we all agree that it's not what the user sees :)
What functionality are you lacking? (Both in screen and print.)
Like, adding contextual content for print. Just like your main content
On 7/19/05, Ian Hickson [EMAIL PROTECTED] wrote:
b) To capture the essence of the browsing session, I would like to build
a breadcrumb at the bottom of the printed page, displaying titles and
urls of pages the user have visited on the site during this visit.
That seems like something that
On 7/13/05, Dean Edwards [EMAIL PROTECTED] wrote:
Matthew Thomas wrote:
Dean Edwards wrote:
We don't display them. Should we?
The native version does. See the Date-Picker section of
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwue/html/ch08c.asp.
OK. We'll show
On 7/6/05, Ian Hickson [EMAIL PROTECTED] wrote:
It isn't a data schema language (although I suppose HTML has been abused
for worst things).
Why not? And what does abuse have anything to do with this? Could you
please elaborate?
:DG
IMHO, one of the biggest obstacles for growth in Web applications
development is the fact that the entire application lives in the scope
of one request.
Once next request is made, the browser essentially forgets
everything and the whole new cycle of loading, initialization, and
binding begins.
I guess I am still struggling to grasp the concepts, so please be
patient with me.
Isn't the main functional value behind the canvas element is the
rendering context? If so, what is the significance of the canvas
element itself? Take away the behavior, and you've got yourself
another SPACER tag.
On 4/20/05, Anne van Kesteren [EMAIL PROTECTED] wrote:
Isn't the main functional value behind the canvas element is the
rendering context? If so, what is the significance of the canvas
element itself? Take away the behavior, and you've got yourself
another SPACER tag.
Not really. Since
14 matches
Mail list logo
