Nabble - w3.org - www-html

Re: The future of HTML - enlighten me?

2009-11-03T11:54:01Z

On Tue, Nov 3, 2009 at 9:45 AM, Dustin Boyd <rpgfan3233@...> wrote:
> XHTML 2.0 is no longer being developed and the decision has been made
> to support HTML 5, which has an XML serialisation. With HTML 4.x, XHTML
> 1.x and even through some of the various drafts of XHTML 2.0, I was
> able to take in the information and use the various elements and
> attributes. With HTML 5, it's simply too large. I realise that XHTML
> 2.0 was moving too slowly, but the simplicity made it rather nice.
> HTML 5 on the other hand appears to be going the way of a programming
> API, where you need a constant reference, reducing the usefulness.

One of the major goals of HTML5 is to support complex web
applications. The spec was originally named Web Applications 1.0, in
fact. It does have plenty of nice new features for regular authors
too, though, like <video>/<audio>, and better specification of
existing functionality to improve interoperability. Also (arguably)
the fact that you can use non-XML syntax is good for authors, although
of course some people think XML is better.

> Honestly, a lot of features are being asked for, but how many of those
> requested features will be used enough to warrant their additions in
> practice?

All of them. Otherwise they wouldn't have been added. However, there
are a bunch that are only relevant to scripted pages, of course.

> I know the same argument about HTML 5 being "bloated" has been made
> before, and I also know that alternatives deemed as being "viable" are
> rarely made. However, it needs to be cut down somehow. It's too
> complex to be considered practical.

Some features have been split out into separate specifications (e.g.,
Web Storage), and more might be in the future. The spec is definitely
too complicated for the average author to understand completely, of
course, but the large majority of authors don't have to read the spec
itself. Also, it becomes much shorter if you use the whatwg.org
version and click "Hide UA text".

> At this point, removing features
> seems to be a ridiculous idea. Starting from scratch isn't very
> appealing either. If features were to be removed, how would anybody
> decide which features to omit? It seems as if several elements and
> attributes are intertwined with others. This makes the prospect of
> removing features seems rather implausible.

Thankfully, we have a talented, hard-working editor who's willing to
put in the work to do stuff like split things out into separate specs.

> Oh, and while I like the idea of the CANVAS element, does such a thing
> really belong in a markup language used for conveying information?

HTML5 is not only for conveying information, it's also meant to help
web apps. Only a subset of it is useful for traditional static web
pages. Splitting out most of <canvas> into a separate specification
is being considered, last I heard. FWIW, I'm pretty sure <canvas> is
its own element rather than <object>-based or such because it was
originally reverse-engineered from a WebKit-specific element, and the
WebKit developers chose to call it <canvas> rather than using
<object>.

> Is there going to be another Dark
> Age for the Web? HTML 4's strict definition made an effort to remove
> the things that created the first Dark Age, things like FONT elements
> and other presentational items as well as inaccessible items like
> FRAMESETs. In my opinion, HTML 5 as a whole is a regression rather
> than a natural progression.

HTML5 goes further than HTML4, and makes <font> and <frameset>
completely non-conforming. What about it do you think might lead to a
Dark Age?

The future of HTML - enlighten me?

2009-11-03T06:45:20Z

XHTML 2.0 is no longer being developed and the decision has been made

to support HTML 5, which has an XML serialisation. With HTML 4.x, XHTML

1.x and even through some of the various drafts of XHTML 2.0, I was

able to take in the information and use the various elements and

attributes. With HTML 5, it's simply too large. I realise that XHTML

2.0 was moving too slowly, but the simplicity made it rather nice.

HTML 5 on the other hand appears to be going the way of a programming

API, where you need a constant reference, reducing the usefulness.

Honestly, a lot of features are being asked for, but how many of those

requested features will be used enough to warrant their additions in

practice?

I know the same argument about HTML 5 being "bloated" has been made

before, and I also know that alternatives deemed as being "viable" are

rarely made. However, it needs to be cut down somehow. It's too

complex to be considered practical. At this point, removing features

seems to be a ridiculous idea. Starting from scratch isn't very

appealing either. If features were to be removed, how would anybody

decide which features to omit? It seems as if several elements and

attributes are intertwined with others. This makes the prospect of

removing features seems rather implausible.

Oh, and while I like the idea of the CANVAS element, does such a thing

really belong in a markup language used for conveying information?

After all, the canvas API could be retained since it would rely on an

external implementation such as JavaScript, but why couldn't something

like the OBJECT element be used rather than a dedicated element?

Is HTML 5 actually being defined as a markup language as the name

suggests or is it turning HTML into a programming language? If it's

becoming a programming language, why is it still defined as "HyperText

Markup Language" rather than "HyperText Programming Language"? Is

HTML 5 really headed in the right direction? Should it be split into

different sections to separate the programming from the markup? Or

perhaps those who want a simple language should just use XSLT to

transform XML documents to HTML 4.x or XHTML 1.x. After all, HTML 5

doesn't seem to be for authors. That is not to say that HTML 5 is

completely useless. I'm merely trying to make a point of the fact

that HTML 5 is more like "HTML for browser vendors". The "Author"

view for the HTML 5 specs on the WHATWG site is rather useful, but it

still has a lot of things that appear to be more beneficial to

implementors than to the authors that create the documents. Again,

this makes me wonder whether HTML 5 is being defined as its name

suggests or whether it is becoming a programming language instead of a

language for conveying information. Is there going to be another Dark

Age for the Web? HTML 4's strict definition made an effort to remove

the things that created the first Dark Age, things like FONT elements

and other presentational items as well as inaccessible items like

FRAMESETs. In my opinion, HTML 5 as a whole is a regression rather

than a natural progression.

Of course, all of this is purely my opinion. Feel free to direct me

toward answers that can perhaps enlighten me to the true nature of

HTML 5 because all I can see, even with my open mind, is something far

too complex to use.

Fwd: XHTML modularization versions and earlier specifications

2009-11-01T12:16:57Z

Hello www-html,

I sent the message below about using newer versions of XHTML modularization
DTD modules with specifications predating it to public-qa-dev but have not
received a reply. Perhaps someone here can shed some light on the issue?

Ville

---------- Forwarded Message ----------

Subject: XHTML modularization versions and earlier specifications
Date: Sunday 25 October 2009
From: Ville Skyttä <ville.skytta@...>
To: "public-qa-dev" <public-qa-dev@...>

Hello,

I added XHTML modularization 1.1 modules and entities to the markup validator
and its catalogs today in CVS. This improves things as there are a few XHTML
based specifications that use these modules, and previously there were no
local copies of these files for general use in the validator, resulting in
them being fetched from www.w3.org on demand which is not that cool.

I also thought I'd clean up duplicates and "private" versions of these modules
from validator's DTD dirs of various specifications, but now I have a
question:

Is it ok to upgrade the modules/entities/etc referred to in some
specifications to the newest versions of those files, provided that their
public ids have not changed even if their contents have?

For example, many XHTML Basic 1.0 DTD modules do have same public ids as the
XHTML modularization 1.1 ones, but many of them have seen some changes since
XHTML Basic 1.0 was released. Would it be ok from validation/conformance
point of view to use the XHTML modularization 1.1 ones nevertheless, or is
e.g. XHTML Basic 1.0 stuck with the exact versions that were in effect (and
that are distributed with the XHTML Basic 1.0 DTD) at the time it was
released?

I *think* it'd be ok to upgrade if the public ids haven't changed, but wanted
to hear more educated opinions before proceeding further with these changes.
It'd be a shame if not for catalog and other maintenance reasons.

-------------------------------------------------------

RE: DTD XHTML-1.0-Transitional issue

2009-10-06T02:59:42Z

Works fine for me too

Ganesh J. Acharya

-----Original Message-----
From: www-html-request@... [mailto:www-html-request@...] On Behalf Of
Steven Pemberton
Sent: Monday, October 05, 2009 6:11 PM
To: Tony Phillips; www-html@...
Subject: Re: DTD XHTML-1.0-Transitional issue

It works for me. I think it may be an internal problem at your end. I'll
contact you separately.

Best wishes,

Steven Pemberton

On Fri, 02 Oct 2009 17:14:56 +0200, Tony Phillips <tonyph@...>
wrote:

> We were trying to use the DTD XHTML-1.0-Transitional and found that the
> DTD/xhtml1-transitional.dtd file doesn't exist (
> http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd cannot be found).
> Is this a known issue?
>
> Thanks,
> Tony Phillips
> IBM Software Engineer
> Information Protection Services
> Business Continuity and Resiliency Services

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.409 / Virus Database: 270.14.3/2410 - Release Date: 10/05/09
06:19:00

Re: DTD XHTML-1.0-Transitional issue

2009-10-05T08:58:15Z

Tony Phillips wrote:

> We were trying to use the DTD XHTML-1.0-Transitional and found that
> the DTD/xhtml1-transitional.dtd file doesn't exist (
> http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd cannot be
> found). Is this a known issue?

It's strange, anyway.

On IE 8, on Vista, trying to access the URL results in a page that says just
see http://w3.org/brief/MTE2

On Firefox 3, the browser prompts what to do, and answering WordPad makes
the DTD document to be displayed.

On Opera 10, I get a prompt asking what to do with
xhtml-transitional.dtd.raw, with no useful option except saving the data on
disk.

What on..., I'm asking.

Here's what I get in response to simple HTTP request:

HEAD /TR/xhtml1/DTD/xhtml1-transitional.dtd HTTP/1.1
Host: www.w3.org

HTTP/1.1 200 OK
Date: Mon, 05 Oct 2009 15:01:58 GMT
Server: Apache/2
Content-Location: xhtml1-transitional.dtd.raw
Vary: negotiate,accept-encoding
TCN: choice
Last-Modified: Thu, 01 Aug 2002 18:37:56 GMT
ETag: "7d6f-3a72ac59d0900;45a3e4327da00"
Accept-Ranges: bytes
Content-Length: 32111
Cache-Control: max-age=7776000
Expires: Sun, 03 Jan 2010 15:01:58 GMT
P3P: policyref="http://www.w3.org/2001/05/P3P/p3p.xml"
Connection: close
Content-Type: application/xml-dtd; charset=utf-8

I think someone is outsmarting themselves...

--
Yucca, http://www.cs.tut.fi/~jkorpela/

Re: DTD XHTML-1.0-Transitional issue

2009-10-05T05:40:48Z

It works for me. I think it may be an internal problem at your end. I'll
contact you separately.

Best wishes,

Steven Pemberton

On Fri, 02 Oct 2009 17:14:56 +0200, Tony Phillips <tonyph@...>
wrote:

DTD XHTML-1.0-Transitional issue

2009-10-02T08:14:56Z

We were trying to use the DTD XHTML-1.0-Transitional and found that the DTD/xhtml1-transitional.dtd file doesn't exist (http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd cannot be found). Is this a known issue?

Thanks,

Tony Phillips
IBM Software Engineer
Information Protection Services
Business Continuity and Resiliency Services

Re: XHTML 1.1 spec: lang and xml:lang (PR#10217)

2009-09-16T07:02:42Z

Thanks for your comment.

@lang is not deprecated, and no, it does not need to be included in the module
in XHTML M12N. We have chosen to incorporate it into XHTML 1.1 because several
groups have demonstrated a need for it. The rules specified describe the
relationship between @lang and @xml:lang.

> Hello,
>
> I've looked at the latest XHTML spec from 2009-05-07. Referring to
>
> http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_com...
>
> In the I18N module, there are only two attributes listed: dir and xml:lang.
The
> note in the last paragraph says: "Finally, note that the I18N collection only
> contains the xml:lang attribute unless the Bi- directional Text Module module
is

> selected." This is fine, but...
>
> http://www.w3.org/TR/xhtml11/doctype.html
>
> says (last paragraph):
>
> "This specification also adds the lang attribute to the I18N attribute
> collection as defined in [XHTMLMOD]. The lang attribute is defined in
> [HTML4]. When this attribute and the xml:lang are specified on the
> same element, the xml:lang takes precedence. When both lang and
> xml:lang are specified on the same element, they SHOULD have the same
> value."
>
> Is the 'lang' attribute deprecated? If it is not, it should be in the
> I18N module as well. If it *is* deprecated,
>
> http://www.w3.org/TR/xhtml11/doctype.html
>
> is basically wrong, isn't it?
>
> What's the status on lang now?
>
> Karsten
>
>
>

Marked addEventListenerNS and removeEventListenerNS At Risk

2009-09-12T14:30:48Z

Hi, DOM3 Events folks-

(BCC to groups potentially affected.)

I have marked addEventListenerNS and removeEventListenerNS at-risk in
the latest Editor's Draft of the DOM3 Events specification [1]. This
means that we are gathering information on whether we can safely remove
these methods from the specification.

Apparently, these are not yet implemented in desktop browsers, so there
has been a call to reexamine their inclusion in this specification. I
personally suspect that there is not much of an implementation burden
regarding these methods, but I would welcome implementer feedback on the
matter.

I don't know how widely deployed other implementations are, nor how much
content relies on these methods. I do note that it is supported in
Batik [2] and Inkscape, and more generally in Java implementations of
the DOM. I believe that other W3C specifications may rely on it (XML
Events [3], maybe XForms). Any evidence that removing these methods
from the specification should be sent to www-dom@....

We also welcome use cases in favor of retaining or removing them. My
inclination is to retain the namespace-aware methods, since there are
existing implementations, so evidence that removing them will be
beneficial will have to be pretty strong, but it's on the table.

Thanks for your feedback.

[1]
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html?rev=1.80
[2]
http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/events/NodeEventTarget.html#addEventListenerNS%28java.lang.String,%20java.lang.String,%20org.w3c.dom.events.EventListener,%20boolean,%20java.lang.Object%29
[3] http://www.w3.org/TR/xml-events/

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

French Translation--of "Advanced HTML"--has a new URL

2009-09-08T09:13:03Z

Hi!

My French translation of Dave Raggett's "Advanced HTML" (http://www.w3.org/MarkUp/Guide/Advanced.html)
is now lodged at a new URL:

http://reflectionsonlandusetranslationsmorebycew.com/Creezunhabitatweb/RaggettHTMLavance.html

(This link has been updated already at the w3c translators' page--this is just a copy of an email I'd already sent to the translators' list!)

However, the old URL (http://www.geocities.com/quaiouestenglish/Creezunhabitatweb/RaggettHTMLavance.html)
has a redirect for the duration of the month.

Best,

C. E. Whitehead
cewcathar@...

a good webiste :www.electronics-seller.com

2009-08-28T12:06:12Z

Dear friend:
how are you doing lately?i would like to introduce a good company who trades mainly in electornic products. such as motorcycles, laptops, mobile phones, digial cameras, LCD TV, x box, PS3, GPS, MP3 / 4, etc.
Now the company is under sales promotion,all the products are sold nearly at its cost.
They provide the best service and original products of
good quality, moreover ,the price is a surprising happiness to you!
It is realy a good chance for shopping.just grasp the opportunity,Now or never!
http://www.electronics-seller.com

XHTML 2.0 Table - axis attribute

2009-07-23T20:04:46Z

Hello.

I request to change the axis attribute to a space-separated list of values
in XHTML 2.0

Current definition:
"This attribute may be used to place a cell into conceptual categories that
can be considered to form axes in an n-dimensional space. User agents may
give users access to these categories (e.g., the user may query the user
agent for all cells that belong to certain categories, the user agent may
present a table in the form of a table of contents, etc.). Please consult
the section on categorizing cells for more information. The value of this
attribute is a comma-separated list of category names."
http://www.w3.org/TR/2004/WD-xhtml2-20040722/mod-tables.html#adef_tables_axi
s

It is inconsistent with other attributes supporting lists of values by
separating them with space. For example the headers attribute in the table
module.
Furthermore it makes it impossible to cooperate with css selectors which
also define
attribute selectors of space separated values (ex. E[foo~="warning"]) but
not for comma separeted values. And since the purpose of AXIS is to support
a filtering capability this can be very important.

Greetings
Tobias Schultze

Btw: I also posted it at
http://htmlwg.mn.aptest.com/cgi-bin/xhtml2-issues?findid=8061 but
that tracker seems to be dead.

What Kind of a Group is this and How I become member of this group?

2009-06-29T13:11:35Z

Hello,

What kind of a Group is this and how I become member of this group? Is
there any Member or Moderator or Admin know me well?

Please send more information or unsubscribe me!

Thanks

Kamaal
--
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "IBroadcast Qatar" group.
To post to this group, send email to ibroadcast-qatar@...
To unsubscribe from this group, send email to ibroadcast-qatar+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/ibroadcast-qatar?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: [html] Elements within "title"?

2009-06-16T16:22:21Z

I don´t think either!

I think it will even get worse for rankings.

Thanks.

Marcos

http://www.otimizacao-de-websites.com

Validation of WAI ARIA and RDFa in XHTML?

2009-06-03T00:27:20Z

Hello,

is there a way to validate XHTML 1.0 STRICT which uses WAI ARIA *and*
RDFa? If not are there any plans to make it possible?

Regards,
Mirko

Re: form inside tabular data

2009-05-19T06:16:10Z

On Tue, May 19, 2009 at 6:53 AM, Octavio Alvarez <alvarezp@...> wrote:

On Mon, 18 May 2009 04:42:56 -0700, Philip TAYLOR (Ret'd) <P.Taylor@...> wrote:

> David Dorward wrote:
>
>> One form around the entire table, with the name of the successful submit
>> button being used to determine which row is being acted upon. (We should
>> be able to use value, but IE7 and lower have broken implementations of
>> <button>).
>
> But the original question was how to have multiple forms
> within a single table (one per row), not how to be able
> to differentiate from within which row a particular
> "Submit" operation took place.

Why would you need to have multiple forms (read: multiple forms with
different actions each), one per row, given that properly tabulated
data should be similar in type?

so you suggest to use a single form, and differentiate the data, based on the submit?

<form action="emailgestor.php">
<table>
<tr>
<td><input type="checkbox" name="email_1"> favorite</td><td>Re: forms</td><td><input type="submit" name="reply_1" value="Reply"><input type="submit" name="delete_1" name="Delete"></td>
</tr>

.
.
.
.
<tr>
<td><input type="checkbox" name="email_30"> favorite</td><td>Re: looks mom, no hands</td><td><input type="submit" name="reply_30" value="Reply"></td><td><input type="submit" name="delete_30" name="Delete"></td>
</tr>
</table>
</form>

On the server:

for($t=1;$t<=$maxemails;$t++){
   if (isset ( $_POST["reply_" . $t] ) ) {
           replyEmail($t);
   } else if (isset( $_POST["delete_". $t] ) ) {
          deleteEmail($t);
}
if (isset( $_POST["delete_". $t] ) && $_POST["delete_". $t] == "on" ) {
          favoriteEmail($t, true);
} else {
         favoriteEmail($t,false);
}
}

humm... maybe this work.

--
--
ℱin del ℳensaje.

Re: form inside tabular data

2009-05-18T23:48:57Z

Octavio Alvarez wrote:

> Why would you need to have multiple forms (read: multiple forms with
> different actions each), one per row, given that properly tabulated
> data should be similar in type?

That is not for me to say. I was simply pointing out that David's
proposal did not address the problem.

Philip TAYLOR

Re: form inside tabular data

2009-05-18T21:53:36Z

On Mon, 18 May 2009 04:42:56 -0700, Philip TAYLOR (Ret'd) <P.Taylor@...> wrote:

> David Dorward wrote:
>
>> One form around the entire table, with the name of the successful submit
>> button being used to determine which row is being acted upon. (We should
>> be able to use value, but IE7 and lower have broken implementations of
>> <button>).
>
> But the original question was how to have multiple forms
> within a single table (one per row), not how to be able
> to differentiate from within which row a particular
> "Submit" operation took place.

Why would you need to have multiple forms (read: multiple forms with
different actions each), one per row, given that properly tabulated
data should be similar in type?

Re: form inside tabular data

2009-05-18T04:42:56Z

David Dorward wrote:

> One form around the entire table, with the name of the successful submit
> button being used to determine which row is being acted upon. (We should
> be able to use value, but IE7 and lower have broken implementations of
> <button>).

But the original question was how to have multiple forms
within a single table (one per row), not how to be able
to differentiate from within which row a particular
"Submit" operation took place.

I agree with your earlier analysis that permitting
<form> to appear within <tr> is the most appropriate
solution.

Philip TAYLOR

Re: form inside tabular data

2009-05-18T04:18:20Z

> you have lots of tabular data, that use <table> <tr> <td>.
> every line on the table is a form
>
> <tr>
> <form><td><input type="text" name="price_21" value="5"
> /></td><td><input type="submit" value="Change price for product 21"
> /></td></form>
> </tr>
>
> Ouch!

It is invalid, but aside from that I see little reason for an "Ouch!". In
this instance, the table looks like it is being used for layout, but I'll
assume that is a simplified example.

> <tr>
> <td><form><input type="text" name="price_21" value="5"
> /></td><td><input type="submit" value="Change price for product 21"
> /></form></td>
> </tr>
>
> Ouch!

This is invalid, but also non-well formed.

> Proposed solution:
> <tr>
> <td><input type="text" form="product_21" name="price_21" value="5"
> /></td><td><input type="submit" form="product_21" value="Change price
> for product 21" /></td>
> </tr>
>
> ...
>
> <form id="producto_21"></form>

Frankly - yuck. I don't see any reason to move the relationship between
forms and form controls from a hierarchy based on one to a attribute
linkage one.

Allowing forms around table rows would (afaik) be backwards compatible
with the error correction in most existing user agents.

> If theres a prefered solution available, whitin the current standards,
> It will be much preferable, but is unknom to me, and to others web
> authors asked about the topic.

One form around the entire table, with the name of the successful submit
button being used to determine which row is being acted upon. (We should
be able to use value, but IE7 and lower have broken implementations of
<button>).

--
David Dorward
http://dorward.me.uk/

form inside tabular data

2009-05-18T03:19:58Z

Hello,

I am a web author, and I am decide to raise a problem for the
examination of this mail list. I understand the purpose of this mail
list is to discuss changes on the standards, and my problem may need
that.

Problem:

you have lots of tabular data, that use <table> <tr> <td>.
every line on the table is a form

<tr>
<form><td><input type="text" name="price_21" value="5"
/></td><td><input type="submit" value="Change price for product 21"
/></td></form>
</tr>

Ouch!

<tr>
<td><form><input type="text" name="price_21" value="5"
/></td><td><input type="submit" value="Change price for product 21"
/></form></td>
</tr>

Ouch!

Proposed solution:
<tr>
<td><input type="text" form="product_21" name="price_21" value="5"
/></td><td><input type="submit" form="product_21" value="Change price
for product 21" /></td>
</tr>

...

<form id="producto_21"></form>

what?: it take a undefined state ( input widgets living outside form
blocks ) and add a key to attach these orphan widgets to a existing
form.

If theres a prefered solution available, whitin the current standards,
It will be much preferable, but is unknom to me, and to others web
authors asked about the topic.

Theres a alternate solution, that use javascript, but I prefered a
html-only solution.

--
--
ℱin del ℳensaje.

Reuse of the 1999 namespace is potentially misleading/wrong... for XHTML2

2009-05-17T10:40:56Z

Followers of this list may know this subject, since a similar
discussion was raised in the HTML WG. There, it was decided that
reusing the 1999 namespace is part of their design choice. But for
XHTML2, why do you have to reuse it?
In particular, could you point me to the relevant discussion about it?
All I could find on it was before the split and rechartering of HTML
and XHTML working groups, which means that members had other points of
view.

Nowadays, with HTML5 taking the backward compatible part of the web
and all its quirks and annoyances, I think that XHTML2 should start
completely anew, get a new namespace and drop legacy elements
(including <hN>,<a>,<img>).
Doing this, you can avoid all problems that resulted to the too wide
use of HTML by authors not aware of standards, all problems of browser
wars, all problems of broken guides/tutorials, that have created the
mess HTML4/5 currently is, including fake XHTML (and the compatibility
guidelines).

In addition, I think that XHTML should take advantage of XML
namespaces saying that:
- foreign content is allowed everywhere, if it is in a different namespace
- in particular, XForms elements must be in the XForms namespace
- XForms Common attributes can be in XHTML2 elemenst if they're
namespaced (thus allowing to attach XForms repetition and binding to
XHTML2 elements)
- XHTML2 attributes can be in XForms elements if they're namespaced
(for example if you want an image button)
- XMLEvents1/2 attributes must be namespaced also in XHTML2 elements
- XMLEvents1/2 elements must be always namespaced
All of this namespaces are required because they all define ortoghonal
technologies, that fit well the CDF model with elements' and global
attributes' semantic given by its namespace, irrelevant of its parent.

I hope that this will start a positive discussion,

Giovanni

RE: Missing Functionality: Include

2009-05-11T18:04:40Z

Elliot Jenner wrote:
>
> Coming from programming languages like C++ and Python, I naturally
> expected that it would be similarly simple to move redundant parts of
> the page into external files and then include them back in. After
> extensive searching, I determined that this basic functionality is
> missing from the language, and requires such hefty workarounds as
> server-side-scripting or PHP.

Perhaps it is because HTML is not a *programming* language, but rather a
mark-up language, two very different animals. HTML (Hyper Text Markup
Language) is about applying structure and meaning to text, and not about
spinning wheels, dancing flames or other wondrous adventures; it is about
conveying meaning to your data and information.

> It should not be necessary to go to a
> completely different language to perform such a necessary task,
> particularly languages that require the added complication of a web
> server just to see if your code is functioning properly, and the added
> worry that some servers may not support the scripting.

Say what? Hefty? At the most basic level, Apache web servers allowed you to
do just this since nearly the beginning of time itself, simply by adding:



And ensuring that your server (your compiler as it were) was configured to
respect that command. See:
http://httpd.apache.org/docs/1.3/howto/ssi.html

Subsequently, with PHP it is as simple as:

<?php
include ("/foo.html");
?>

And again ensuring that your server is configured correctly. Pretty much
every installation of Apache today offers PHP support out of the box.

Not using Apache? IIS also allows for server-side inclusion via ASP:





Again out of the box. These are 'hefty'?

As for testing; if you are looking to use PHP, investigate XAMPP (windows)
or XAMPP for Mac OS X - both allow for local testing without the need to
'upload' anything. Want Windows testing, try starting here:
http://support.microsoft.com/kb/839013

>
> Am I alone in wishing for a simple <include url('file.html')/> element
> or something similar that allows this to be accomplished easily?

See above (SSI). The three 'planks' of modern web development continue to
be HTML for semantic structure, CSS for 'display', and scripting (client
side or server side) for 'functionality', and I for one hope it remains this
way. As an aside, while server-side scripting *does* have a higher cost to
the developer (server and bandwidth), it is also a more predictable method,
and as such is likely the better choice for functionality such as what you
are seeking (IMHO). I'm still not a big AJAX guy, but believe that there is
a means using xmlhttprequest to also do something similar

> In my
> opinion this is a completely basic function that any language should
> have. How did CSS, which was developed later, obtain the <link> tag,
> meanwhile the older HTML standard still lacks it?

As others have pointed out, <link> in HTML existed prior to CSS, and was
simply used in the early days to link an external CSS file to an HTML
document. We also now have @import...

> Particularly on a
> website, there will always be bits of code that are common to all the
> various pages that make it up, for example the navigation and copy
> write/contact code.

Yep, those requirements have been around for some time now (certainly the
decade or so that I've been playing here), but understanding the history of
what came before will hopefully clarify both reasoning and current
methodologies better.

Cheers!

JF

Re: Missing Functionality: Include

2009-05-11T09:17:51Z

Aryeh Gregor wrote:

> Semantic HTML only gets you so far: there are still usually large
> chunks of repeated HTML on every page, for navigation bars and
> so on.

This is annoying from an aesthetic standpoint, but may not matter
except on very limited devices, such as mobile browsers.

> I admittedly haven't benchmarked the actual performance
> difference from a 20% reduction in the size of a fairly large
> HTML page, say -- it might not be too large.

I think this might be somewhat covered by the microscape benchmark.

http://www.w3.org/Protocols/HTTP/Performance/microscape/

While the results I read are out of date, I wouldn't be surprised to
discover that the following points still hold:

(a) Total number of requests often matters more than total number of
bytes. So splitting something into separate includes may be
counterproductive. (Thus the yahoo UI libraries come pre-bundled.)
(b) If the page is slow enough that people notice, getting rid of the
text entirely won't save as much as better compression (or
elimination) of images.

-jJ

Re: Missing Functionality: Include

2009-05-11T06:32:38Z

On Mon, May 11, 2009 at 1:52 AM, David Woolley
<forums@...> wrote:
> One final point is that, if you look at typical commercial web sites, they
> are so bloated with style attributes, embedded style sheets and Javascript
> libraries, that is clear that the authoring community doesn't actually care
> about keeping transmitted page sizes down. Cleanly written semantic HTML is
> actually rather compact and fast to load.

This is true for most websites, but there are a lot of websites
(especially those based on major software packages, rather than built
in-house) that do try to minimize loading time. Semantic HTML only
gets you so far: there are still usually large chunks of repeated HTML
on every page, for navigation bars and so on.

I admittedly haven't benchmarked the actual performance difference
from a 20% reduction in the size of a fairly large HTML page, say --
it might not be too large. In that case, this is probably more
complexity than it's worth, especially given its inflexibility. As
Roland rightly points out, it wouldn't work well if you want to
highlight the current location or whatnot, which is common. <iframe
seamless> from HTML5 would replicate almost all of the functionality
anyway, and AJAX can minimize downloaded content better than any sort
of declarative include like this.

XHTML 1.1 spec: lang and xml:lang

2009-05-11T05:57:27Z

Hello,

I've looked at the latest XHTML spec from 2009-05-07. Referring to

http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_com...

In the I18N module, there are only two attributes listed: dir and xml:lang. The note in the last paragraph says: "Finally, note that the I18N collection only contains the xml:lang attribute unless the Bi- directional Text Module module is selected." This is fine, but...

http://www.w3.org/TR/xhtml11/doctype.html

says (last paragraph):

"This specification also adds the lang attribute to the I18N attribute
collection as defined in [XHTMLMOD]. The lang attribute is defined in
[HTML4]. When this attribute and the xml:lang are specified on the
same element, the xml:lang takes precedence. When both lang and
xml:lang are specified on the same element, they SHOULD have the same
value."

Is the 'lang' attribute deprecated? If it is not, it should be in the
I18N module as well. If it *is* deprecated,

http://www.w3.org/TR/xhtml11/doctype.html

is basically wrong, isn't it?

What's the status on lang now?

Karsten

Re: Missing Functionality: Include

2009-05-11T05:03:37Z

Elliot Jenner wrote:
> Virtually the sole purpose of the link element is to include CSS. Since
> it is almost never used for anything else, I consider it part of CSS for
> all intents and purposes.

This is a misunderstanding at your side. The link element doesn't
/include/. It carries /information about a relationship/ to other
documents. So to speak, other documents are /assigned/ to the document
in question. It is entirely up to the user agent how to respond to
getting knowledge of such relationship. In the case of CSS and a UA
capable of processing CSS, it would normally request the CSS document
and apply its rules to the representation of the document.
Aryeh has informed you about other widely deployed uses of the element.

> What I am suggesting for a future version (and hopefully a backport) is
> a simple tag command, say <include href="file" /> that takes the
> contents of the file in question and places it into the position it
> occupies, similar to what a <link href="file" type="text/css" /> does
> now for CSS, but without any type of formatting.

I notice the absence of the rel attribute in your example, again
indicating the misunderstanding of the link element. The style sheet
assignment is not denoted by type="text/css", it is denoted by naming
the kind of relationship to the CSS document, i.e. rel="stylesheet".

Regarding the introduction of some kind of inclusion mechanism to HTML,
I predict the story would go like this: After agreeing on an <?include?>
processing instruction, the next inevitable extensions would be
conditional statements and variables, because people feel the urgent
need to implement hierarchical menus with the current item highlighted.
(But we already have that, it is called server side includes, only that
SSI is a server-side technique.) Then people want to more cleanly
separate content and presentation and thus need a variety of loops and
the possibility of loading data files or querying an RDBMS. (Again we
have that, it's called PHP, and it also works without a server
environment.) Soon we would have another full-blown programming language
-- or several such languages, because people tend to develop strong
feelings about what would be the right[tm] syntax for all this stuff. So
we would separate the programming from HTML again and only do some kind
of designating or referencing within HTML. Yet again, we already have
this, just in the other direction: we would designate HTML chunks and
programming statements from within a build provision called Makefile.

And so I approach the practical part of your question (how to get your
problem solved). I suggest you deploy some kind of preprocessor in
conjunction with the build system of your choice.

As for the preprocessor, you could use CPP, which you already know from
C++, but I'm afraid it is syntactically unpleasant within HTML.

A good choice imho would be PHP. Indeed, this task is the original
purpose of PHP (and imho the only application which it is good for). It
has a simple C-like syntax and all the control structures you need. And
an include statement, too.

Then there was a very interesting project called Website Meta Langauge,
featuring file inclusion, macro expansion, embedded Perl and output
splitting. Unfortunately it appears to have been abandoned. When I once
tried, I didn't even manage to make it build. Otherwise this would be my
favourite for the task. http://thewml.org/

As for the build system, there's an abundance available these days.
http://en.wikipedia.org/wiki/List_of_build_automation_software

At the end of the day, HTML is not meant to be a programming language,
it's meant to markup text.

Re: Missing Functionality: Include

2009-05-10T22:52:04Z

Elliot Jenner wrote:
> Virtually the sole purpose of the link element is to include CSS. Since
> it is almost never used for anything else, I consider it part of CSS for
> all intents and purposes.

Using link for CSS was added quite late. The main problem with link was
that it was that the market leading GUI browsers failed to implement it,
probably because there was no author controlled rendering, and they were
in the WYSIWYG market not the true HTML market.

>
> As to frames and the object usage, these have a tendency to fail at best
> and be outright mishandled by servers at worst. I realize that these
> exist, and have used them, but I have been frustrated by the spotty
> functionality and the difficulty of implementation.

I don't understand why you think people have problems with frames. When
frames came out, almost ever commercial web site used them. That they
are less used now is probably the result of education. Frames are
incompatible with the URL concept, because you cannot link to a framed
page after an internal link has been followed.

The big problem with object was that it was hijacked by Microsoft for
supporting ActiveX embedded applications, and their implementation of
basic object inclusion was poor.
>
>
> What I am suggesting for a future version (and hopefully a backport) is
> a simple tag command, say <include href="file" /> that takes the

This is an element, not a tag, and elements should always be
declarative, never commands. Although I'm not sure that inclusion would
be a valid use, commands should be implemented using processing
instructions, not elements.

However, as already hinted, HTML, as an application of SGML, has had an
inclusion facility from the beginning. The problem was that browser
developers did not see fit to actually implement it. The mechanism that
is used to give symbolic names to characters is actually being used for
only a very special case, and should be usable to include whole
fragments of text. As the SGML specifications are not free, and I
haven't had a business need to buy them, I can't be completely sure that
markup is allowed in external entities, but that would be a relatively
small and consistent extension, even if it isn't naturally available.

The external entity mechanism has the advantage that the entities are
declared near the start of the document, so a fetch for them can be
started before they are actually used.

Frames, though, better fitted with the market demand for something
presentational and stateful, even though they are incompatible with the
fundamentals of the web.

In my view, the way of implementing contents sidebars that actually
fitted in with the concept the gave birth to the web would have been for
browsers to automatically open and keep open a window onto any page
referenced by <link rev="contents"....>. This is a non-starter now, as
it it takes away control of the visual presentation and behaviour from
the author, which is good for the reader, but the market is driven by
authors, not readers.

One final point is that, if you look at typical commercial web sites,
they are so bloated with style attributes, embedded style sheets and
Javascript libraries, that is clear that the authoring community doesn't
actually care about keeping transmitted page sizes down. Cleanly
written semantic HTML is actually rather compact and fast to load.

--
David Woolley
Emails are not formal business letters, whatever businesses may want.
RFC1855 says there should be an address here, but, in a world of spam,
that is no longer good advice, as archive address hiding may not work.

Re: Missing Functionality: Include

2009-05-10T18:36:51Z

On Sun, May 10, 2009 at 7:37 PM, Elliot Jenner <void2258@...> wrote:
> Virtually the sole purpose of the link element is to include CSS. Since it
> is almost never used for anything else, I consider it part of CSS for all
> intents and purposes.

Have you read the HTML spec? <link> has a great many uses. For
instance, in the HTML for the Gmail page I'm on right now, I find:

<link rel="shortcut icon" href="/mail/images/favicon.ico" type="image/x-icon">
<link rel="alternate" type="application/atom+xml" title="Gmail Atom
Feed" href="feed/atom" />

I'm not sure if stylesheets are even the single most common use of
<link>. <style> is probably used as often, and feeds and favicons are
very common. The more esoteric links like "next" and whatnot are used
by some pretty major websites too (e.g., Wikipedia).

> What I am suggesting for a future version (and hopefully a backport) is a
> simple tag command, say <include href="file" /> that takes the contents of
> the file in question and places it into the position it occupies, similar to
> what a <link href="file" type="text/css" /> does now for CSS, but without
> any type of formatting. In other words the parser reaches it, jumps to the
> other file, reads the HTML as it, then jumps back when the file ends and
> continues. This could also be used to import scripts that are duplicated as
> well. The type requirement is not as practical in this instance and could be
> omitted entirely if it is problematic; users advanced enough to be inserting
> scripts should be able to put enough in the include files to make it work on
> just a raw copy anyway.

Obviously the page would have to block while retrieving the <link>, so
latency would be higher for the first request. Other than that, I
think this serves a possibly important use-case: compactness of
markup. Minimizing the length of markup has the potential to reduce
both bandwidth costs (on both ends) and latency on requests other than
the first. This would serve a similar purpose to Google's SDCH:

http://sdch.googlegroups.com/web/Shared_Dictionary_Compression_over_HTTP.pdf

Most pages have very repetitive headers and so on. If these could all
be compressed into a single <link> tag that's only served once, that
might be good for performance. Of course, the HTML documented that's
inserted to replace the <link> tag would follow normal caching rules
-- for this to be very useful, it would have to be served with lengthy
Expires headers. Otherwise you would increase latency on every
request just to get a 304 response.

I don't think this would be a great idea solely for the stated reason,
by the way, because of that. It's all very well to include another
file just for tidiness when that file resides on the local disk, or
hopefully even in RAM, where retrieving it is maybe even (in the case
of compiled languages) a one-time cost. It's quite another thing to
go and fetch lots of includes when they're all the way on the other
end of the Internet. Includes in HTML would need to be used with
care, and only if there's a clear benefit.

I also don't think <link> is appropriate for this. <link> indicates
relationships between documents, it's not a processing instruction. A
name like <include> might be better.

A few further thoughts:

1) The included content (which is probably critical to the page's
meaning) would completely fail to render for legacy user-agents.
Graceful fallback would be difficult, since the whole point is to
avoid including extra code. Of course, authors could just wait for
all important browsers to support the feature, or do some
autodetection magic and serve different pages.

2) The security implications would be more severe than seamless
iframes, etc. It would have to be restricted to same-origin.

3) On the first request, all parsing would have to stop when the
include is encountered. This might not be much worse than <script>
tags, in practice -- but <script> tags would likely be among the
things commonly put *in* these includes, so it could be compounded.
(By contrast, <script>s usually don't attempt to include other
<script>s, at least if well-written.)

4) The way that fast loading of a page that's almost the same as the
current one is currently implemented is generally AJAX. Allowing
sites to avoid JavaScript for this would be a good thing.

5) Presumably JavaScript could add includes when the user clicks a
button to open up a reply form, view more comments, etc. Currently
there are only two ways to do this: a) Code the needed HTML into the
page source or a script include. This increases the weight of every
page load, or at least the first, even though the overwhelming
majority of viewers might not be interested in the functionality. b)
Fetch the needed HTML dynamically when needed. But in this case, it's
not cached, unless it's specifically added to localStorage. Including
content with a proper Expires header would allow the content to be
cached transparently by the browser as space permits, simplifying work
for authors and making more efficient use of disk space (since the
browser can clear its own cache freely, but not localStorage).

This seems like an interesting proposal. Perhaps it should be
considered for inclusion into HTML5, or at least HTML6. It must have
been suggested before at some point, though . . .

Re: Missing Functionality: Include

2009-05-10T16:37:58Z

Virtually the sole purpose of the link element is to include CSS. Since
it is almost never used for anything else, I consider it part of CSS for
all intents and purposes.

As to frames and the object usage, these have a tendency to fail at best
and be outright mishandled by servers at worst. I realize that these
exist, and have used them, but I have been frustrated by the spotty
functionality and the difficulty of implementation.

Additionally, these methods make it very difficult for beginners to
perform basic tasks, discouraging them from creating pages, and are not
handled very well by HTML preview systems (example:Quanta), an
additional deterrent to beginners and annoyance to experienced users
checking for errors.

What I am suggesting for a future version (and hopefully a backport) is
a simple tag command, say <include href="file" /> that takes the
contents of the file in question and places it into the position it
occupies, similar to what a <link href="file" type="text/css" /> does
now for CSS, but without any type of formatting. In other words the
parser reaches it, jumps to the other file, reads the HTML as it, then
jumps back when the file ends and continues. This could also be used to
import scripts that are duplicated as well. The type requirement is not
as practical in this instance and could be omitted entirely if it is
problematic; users advanced enough to be inserting scripts should be
able to put enough in the include files to make it work on just a raw
copy anyway.

By integrating it into the main standard, (provided that it is
emphasized so the browsers support it) you no longer have to worry about
spotty implementation or support on the server side, and it does not
require a large additional learning curve from casual users or
beginners. There should be no need to worry about scripting or server
processing for a basic task like this.

Re: Missing Functionality: Include

2009-05-10T02:27:19Z

I know it (may) seems very bad solution, but it's possible to make an "incude" in JavaScript, which is the client-side scripting language (which HTML is not).

It is a good way to save client-server transfer because you can cache small parts of a web page and don't send them after that to the same user.

They are two way to do it :

* Synchronal system

<script><!--

(function() {

var xhr = new XMLHttpRequest();

xhr.open("GET", "/menu.part.html", false);

xhr.send(null);

document.write(xhr.responseText);

})();

--></script>

If you use a good cache policy on your server for the specified "part.html" file, you can save the transfer of the menu (except the first time the user loads your page).

But it still have the problem it can slow down your page's loading the first time the user loads it.

* Asynchronal system

<div id="menu"><span class="loading">Loading...</span></div>

<script><!--

(function() {

var xhr = new XMLHttpRequest();

xhr.open("GET", "/menu.part.html", true);
xhr.onreadystatechange = function() {

if (xhr.readyState==4) { document.getElementById("menu").innerHTML = xhr.responseText; }

}

xhr.send(null);

})();

--></script>

It have the advantage it don't make your page's first load slower, but it have the disavantage that the menu can be not present during some time the first time you use the page.

Depending on the size of the data you want to cache, using one method or the other can be envisaged.

Regards,

Fremy

From: molte93@...

Sent: Sunday, May 10, 2009 11:07 AM

To: rpgfan3233@...

Cc: www-html@...

Subject: Re: Missing Functionality: Include

When using frames the URL in the browser address bar will not change when you navigate around the site. Therefore a specific page cannot be identified by the URL. So using frames would probably not be a good idea.

Then, of course, you have iframes. But with an iframe you restrict the content of the included page to a specific area - that is not to keep layout and structure separated.

You also refer to a solution using the object element, though, it would need some scripting. It should be possible to include a page without.

All the possible solutions, you refer to, are certainly usable, but when you think about it: Who uses them? Doesn't everybody use a server-side feature for the thing instead? There is probably an explanation to that.

Anyway, wouldn't you be able to include a page using the HTML 5 embed tag (I ask because I do not know)?
----
Molte

2009/5/9 Dustin Boyd <rpgfan3233@...>

On Fri, May 8, 2009 at 23:14, Elliot Jenner <void2258@...> wrote:

>
> Coming from programming languages like C++ and Python, I naturally
> expected that it would be similarly simple to move redundant parts
> of the page into external files and then include them back in. After
> extensive searching, I determined that this basic functionality is
> missing from the language, and requires such hefty workarounds as
> server-side-scripting or PHP. It should not be necessary to go to a
> completely different language to perform such a necessary task,
> particularly languages that require the added complication of a web
> server just to see if your code is functioning properly, and the
> added worry that some servers may not support the scripting.
>
> Am I alone in wishing for a simple <include url('file.html')/>
> element or something similar that allows this to be accomplished
> easily?

You must not have known about frames [1], something that HTML has had
for a long time in one form or another. The exact same technology
also exists in XHTML 1.0 via the frameset DTD [2], albeit with a
couple of changes that affect XHTML in general rather than frames
specifically. Another possibility is the IFRAME element [3]. The
OBJECT element [4] works too, with some minor caveats in the area of
client-side scripting such as JavaScript.

> In my opinion this is a completely basic function that any language
> should have. How did CSS, which was developed later, obtain the
> <link> tag, meanwhile the older HTML standard still lacks it?

Actually, the LINK element is a part of HTML (and XHTML) [5]. It is
simply used to create a relationship between an HTML document and a
CSS document. CSS defines style sheet rules; HTML/XHTML defines
elements. They are completely different languages, though it may
appear as if they all go together because they're used together so
often.

> Particularly on a website, there will always be bits of code that
> are common to all the various pages that make it up, for example the
> navigation and copy write/contact code.

This is why frames are a great tool when you don't have more useful
solutions like server-side scripting/programming available. However,
there are usability issues with frames, something that server-side
scripting fixes (or server-side includes at the very least). I've
personally never used the OBJECT element as a replacement for frames,
but I haven't heard about any bad experiences with it other than
scripting as previously mentioned. Then again, with as much
JavaScript as there is in use these days, I am not surprised that I
hear so little about replacing frames using OBJECT. On the other
hand, it has been over a year since I've heard anything about OBJECT
as a replacement for IFRAME, which is already a replacement for the
not-very-usable HTML framesets that I pointed out at first.

You can see a live example of using OBJECT as an alternative to IFRAME
[6], though I'm not exactly sure how old (or reliable) it is. Again,
there might be scripting issues so stay guarded.

[1] - http://www.w3.org/TR/html4/present/frames.html
[2] - http://www.w3.org/TR/xhtml1/dtds.html#a_dtd_XHTML-1.0-Frameset
[3] - http://www.w3.org/TR/html4/present/frames.html#h-16.5
[4] - http://www.w3.org/TR/html4/struct/objects.html#h-13.3
[5] - http://www.w3.org/TR/html4/struct/links.html#h-12.3
[6] - http://intranation.com/test-cases/object-vs-iframe/

Re: Missing Functionality: Include

2009-05-10T02:07:54Z

2009/5/9 Dustin Boyd <rpgfan3233@...>

On Fri, May 8, 2009 at 23:14, Elliot Jenner <void2258@...> wrote:
>
> Coming from programming languages like C++ and Python, I naturally
> expected that it would be similarly simple to move redundant parts
> of the page into external files and then include them back in. After
> extensive searching, I determined that this basic functionality is
> missing from the language, and requires such hefty workarounds as
> server-side-scripting or PHP. It should not be necessary to go to a
> completely different language to perform such a necessary task,
> particularly languages that require the added complication of a web
> server just to see if your code is functioning properly, and the
> added worry that some servers may not support the scripting.
>
> Am I alone in wishing for a simple <include url('file.html')/>
> element or something similar that allows this to be accomplished
> easily?

You must not have known about frames [1], something that HTML has had
for a long time in one form or another. The exact same technology
also exists in XHTML 1.0 via the frameset DTD [2], albeit with a
couple of changes that affect XHTML in general rather than frames
specifically. Another possibility is the IFRAME element [3]. The
OBJECT element [4] works too, with some minor caveats in the area of
client-side scripting such as JavaScript.

> In my opinion this is a completely basic function that any language
> should have. How did CSS, which was developed later, obtain the
> <link> tag, meanwhile the older HTML standard still lacks it?

Actually, the LINK element is a part of HTML (and XHTML) [5]. It is
simply used to create a relationship between an HTML document and a
CSS document. CSS defines style sheet rules; HTML/XHTML defines
elements. They are completely different languages, though it may
appear as if they all go together because they're used together so
often.

> Particularly on a website, there will always be bits of code that
> are common to all the various pages that make it up, for example the
> navigation and copy write/contact code.

This is why frames are a great tool when you don't have more useful
solutions like server-side scripting/programming available. However,
there are usability issues with frames, something that server-side
scripting fixes (or server-side includes at the very least). I've
personally never used the OBJECT element as a replacement for frames,
but I haven't heard about any bad experiences with it other than
scripting as previously mentioned. Then again, with as much
JavaScript as there is in use these days, I am not surprised that I
hear so little about replacing frames using OBJECT. On the other
hand, it has been over a year since I've heard anything about OBJECT
as a replacement for IFRAME, which is already a replacement for the
not-very-usable HTML framesets that I pointed out at first.

You can see a live example of using OBJECT as an alternative to IFRAME
[6], though I'm not exactly sure how old (or reliable) it is. Again,
there might be scripting issues so stay guarded.

[1] - http://www.w3.org/TR/html4/present/frames.html
[2] - http://www.w3.org/TR/xhtml1/dtds.html#a_dtd_XHTML-1.0-Frameset
[3] - http://www.w3.org/TR/html4/present/frames.html#h-16.5
[4] - http://www.w3.org/TR/html4/struct/objects.html#h-13.3
[5] - http://www.w3.org/TR/html4/struct/links.html#h-12.3
[6] - http://intranation.com/test-cases/object-vs-iframe/

Re: Missing Functionality: Include

2009-05-09T12:40:21Z

Dustin Boyd wrote:

> On Fri, May 8, 2009 at 23:14, Elliot Jenner <void2258@...>
> wrote:
>>
>> Coming from programming languages like C++ and Python, I naturally
>> expected that it would be similarly simple to move redundant parts
>> of the page into external files and then include them back in.

In the good old days, people used to refer to FAQs in matters like this.

> You must not have known about frames [1],

Good for him.

> This is why frames are a great tool

You are trolling ín a rather primitive manner.

The technically correct answer would be that entities offered the mechanism
of simple inclusion in HTML, but browser vendors never bothered implementing
them. Frames are a different beast, and an ugly one.

--
Yucca, http://www.cs.tut.fi/~jkorpela/

Re: Missing Functionality: Include

2009-05-09T12:28:57Z

On Fri, May 8, 2009 at 23:14, Elliot Jenner <void2258@...> wrote:

>
> Coming from programming languages like C++ and Python, I naturally
> expected that it would be similarly simple to move redundant parts
> of the page into external files and then include them back in. After
> extensive searching, I determined that this basic functionality is
> missing from the language, and requires such hefty workarounds as
> server-side-scripting or PHP. It should not be necessary to go to a
> completely different language to perform such a necessary task,
> particularly languages that require the added complication of a web
> server just to see if your code is functioning properly, and the
> added worry that some servers may not support the scripting.
>
> Am I alone in wishing for a simple <include url('file.html')/>
> element or something similar that allows this to be accomplished
> easily?

You must not have known about frames [1], something that HTML has had
for a long time in one form or another. The exact same technology
also exists in XHTML 1.0 via the frameset DTD [2], albeit with a
couple of changes that affect XHTML in general rather than frames
specifically. Another possibility is the IFRAME element [3]. The
OBJECT element [4] works too, with some minor caveats in the area of
client-side scripting such as JavaScript.

> In my opinion this is a completely basic function that any language
> should have. How did CSS, which was developed later, obtain the
> <link> tag, meanwhile the older HTML standard still lacks it?

Actually, the LINK element is a part of HTML (and XHTML) [5]. It is
simply used to create a relationship between an HTML document and a
CSS document. CSS defines style sheet rules; HTML/XHTML defines
elements. They are completely different languages, though it may
appear as if they all go together because they're used together so
often.

> Particularly on a website, there will always be bits of code that
> are common to all the various pages that make it up, for example the
> navigation and copy write/contact code.

This is why frames are a great tool when you don't have more useful
solutions like server-side scripting/programming available. However,
there are usability issues with frames, something that server-side
scripting fixes (or server-side includes at the very least). I've
personally never used the OBJECT element as a replacement for frames,
but I haven't heard about any bad experiences with it other than
scripting as previously mentioned. Then again, with as much
JavaScript as there is in use these days, I am not surprised that I
hear so little about replacing frames using OBJECT. On the other
hand, it has been over a year since I've heard anything about OBJECT
as a replacement for IFRAME, which is already a replacement for the
not-very-usable HTML framesets that I pointed out at first.

You can see a live example of using OBJECT as an alternative to IFRAME
[6], though I'm not exactly sure how old (or reliable) it is. Again,
there might be scripting issues so stay guarded.

[1] - http://www.w3.org/TR/html4/present/frames.html
[2] - http://www.w3.org/TR/xhtml1/dtds.html#a_dtd_XHTML-1.0-Frameset
[3] - http://www.w3.org/TR/html4/present/frames.html#h-16.5
[4] - http://www.w3.org/TR/html4/struct/objects.html#h-13.3
[5] - http://www.w3.org/TR/html4/struct/links.html#h-12.3
[6] - http://intranation.com/test-cases/object-vs-iframe/

Missing Functionality: Include

2009-05-08T21:14:24Z

Coming from programming languages like C++ and Python, I naturally
expected that it would be similarly simple to move redundant parts of
the page into external files and then include them back in. After
extensive searching, I determined that this basic functionality is
missing from the language, and requires such hefty workarounds as
server-side-scripting or PHP. It should not be necessary to go to a
completely different language to perform such a necessary task,
particularly languages that require the added complication of a web
server just to see if your code is functioning properly, and the added
worry that some servers may not support the scripting.

Am I alone in wishing for a simple <include url('file.html')/> element
or something similar that allows this to be accomplished easily? In my
opinion this is a completely basic function that any language should
have. How did CSS, which was developed later, obtain the <link> tag,
meanwhile the older HTML standard still lacks it? Particularly on a
website, there will always be bits of code that are common to all the
various pages that make it up, for example the navigation and copy
write/contact code.