[whatwg] Feedbacl

[Tab Atkins Jr.]

On Tue, Jun 9, 2009 at 10:59 PM, Mike
Weissenborn<mike_weissenborn at yahoo.com> wrote:
> 1) I've used frames in many web pages, and I see this is being dropped.  I
> typically have a selection frame and a result frame.  So links clicked on in
> the 1st frame show up in the second frame.   I then never have to worry
> about managing what's in each frame.  For many pages I can likely use a
> block element like a DIV, but my ISP has size limitations and I have spread
> my pages onto several sites.   I have no problems switching to something
> else but I didn't see anything in the specs except opening a new window to
> accomplish this.   If something else is being used, how will this be
> compatible with older browsers.

In general, frames are bad.  They break bookmarking, are horrible for
accessibility, and don't do anything that can't be accomplished
relatively easily in better ways.

For your particular use-case, it appears you have a really weird ISP.
I'd suggest leaving them and getting a competent one.  ^_^  I can
suggest some privately if you'd like.  Your current setup will be next
to impossible to do properly.

It seems like what you're doing currently is putting common 'site'
navigation in one frame, and page contents in another.  Generally the
way this is done without frames is to use some server-side language
(PHP, etc.) to 'build' your pages, combining one or two 'templates'
files with a 'content' file so that it makes a full page.  That way
you can modify the template files once and have the change reflected
across the entire site automatically.  This is usually rather trivial
to implement, and in the end you have a page with none of the problems
that frames does.

> 2) I am perhaps one of the few I know to use Xforms and I am excited about
> being able to have like capabilities in all browsers.  The implementation
> image I saw looked somewhat different and didn't really describe  what new,
> changed or obsolete.  Personally I want the same capabilities of Xforms;
> being able to save locally, FTP. or URL and this wasn't really identified.
> I don't mind having to make change, I just wamt it to work.
>
> Still on Xforms I would like additional functionality, I think you may have
> dealt with, is being able to reformat/reorder the data via CSS or a datagrid
> to a format the user wishes the data to be viewwed in.  Obviously this may
> be define via code, but I'm hoping the WebForms implementation will allow
> for things such as sortable columns,, re-order columns,  hide/show
> columns...
>
> I don't know if the subject of data binding has ever come up.  I  like the
> data binding in IE, however other browsers don't support this ability and I
> have to use binding in IE and Xforms for firefox.  I would really benifit
> from being able to use the same code for both.  I did notice a Local Storage
> componenet, which I hope some consistent client call  can be done to  Post
> or Sync these to a URL...

Don't know much about XForms, and haven't had cause to look into them,
so can't help you here.

> 3) Xforms or not, I hope anything displayable can be formated appropriately
> using CSS.  There seems to be many browser specific formating settings, is
> there a way to consolidate these with this release to iliminate or reduce
> browse specific CSS settings.

There are very good reasons why no browser allows you full control
over form element styling; namely, security.  A few elements (mainly
<input type=file>) must be handled very carefully to make sure they
can't be abused, and allowing arbitrary styling pushes the door wide
open.

Regardless, though, this is a CSS issue, not an HTML issue, and so
should be on the CSS mailing list.

> 4) not being able to implement #3, somehow within CSS it would then be nice
> to be able have some type of IF statement so additional CSS can be included
> or excluded for non-complient browsers...   Even down the road, the ability
> to include/exclude imports based on broweser capabilities could benifit
> many.  Unless defined, browser builders will continue to build there own
> settings.  Im sure this is out of your control, but perhaps an IF isn't.  I
> hate the idea of having to create a different presentation based on the
> browser, but how does one ever ensure someones browser is compatable or the
> content is dsiplayed appropriately.

Again, CSS issue, not HTML.

> 5) On the CSS, I'm sure builders/browser developer would love an XML
> format.   If there are no CSS format changes perhaps this can be identified
> as a future enhancement/direction.  CSS seems to be areal oddball format
> compared to everything else.

Been discussed (though possibly as an April Fools?).  Doesn't seem to
be any real reason to do this, other than that some people already
have xml generators lying around and would like to use them.

And once more, CSS issue, not HTML.  ^_^

> 6)  I did see some comment about user defined variables in the FAQ.  I see
> know reason why if enbed something called <MIKE> in an html file and the CSS
> attributes should handle whatever needs to be displayed in whatever format.
> No CSS=No display.  The same as it works now..

You're probably thinking about
http://wiki.whatwg.org/wiki/FAQ#HTML5_should_support_a_way_for_anyone_to_invent_new_elements.21
.  As noted in that entry, there are already tons of ways to add
information into a page.  Though it's not directly stated in that
entry, new elements... cause problems.  They're *not* consistently
handled by browsers, and they'll never just work right out of the box,
due to block/inline ambiguity and other issues.

Just use, say, <div class="mike"> (or <p>, <ul>, <table>, or whatever
else is more semantically appropriate).  Same effect, and it actually
works in every browser.

~TJ